Group: pgsql.patches


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