Subject: Assertion failure with small block sizes
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 10/14/2007 10:55:54 AM
Gregory Stark <stark@enterprisedb.com> writes:
> Testing Postgres with a small block size runs into an assertion failure when
> it tries to toast a pg_proc tuple during initdb. I think the assertion is just
> wrong and RELKIND_UNCATALOGUED is valid here.
Uh, what makes you think the assertion is the only problem? The toast
table won't exist yet.
How small is "small" anyway?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Subject: Assertion failure with small block sizes
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 10/15/2007 10:32:47 PM
Gregory Stark <stark@enterprisedb.com> writes:
> If I push the TOAST_TUPLES_PER_PAGE up to 16 I get another failure on the same
> line from trying to toast a sequence. If I add RELKIND_SEQUENCE to the
> assertion then it passes all regression tests even if I push
> TOAST_TUPLES_PER_PAGE up to 1024 -- ie, try to toast everything as far as
> possible. Perhaps heapam.c:1761 should just check for RELKIND_SEQUENCE as
> well.
Hmm. I'm inclined to reverse the tests (there are 3 not just 1) in
heapam.c, so that it explicitly tries to toast only in plain tables,
rather than adding more exclusion cases. Thoughts?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Subject: Assertion failure with small block sizes
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 10/15/2007 11:58:59 PM
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> Hmm. I'm inclined to reverse the tests (there are 3 not just 1) in
>> heapam.c, so that it explicitly tries to toast only in plain tables,
>> rather than adding more exclusion cases. Thoughts?
> Well RELKIND_UNCATALOGED can be usefully toasted in that data can be
> compressed internally.
But by the time we are inserting any data that needs compression, the
relkind should not be that anymore. This would only be an issue if
pg_proc.h itself contained DATA() lines long enough to need toasting.
I argue that that isn't true and isn't likely to become true. (See
ts_debug() for an example of deliberately avoiding such a case...)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
|