[PATCHES] Assertion failure with small block sizes
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. Other places in the code check for both before, for example, creating toast tables. creating template1 database in /home/stark/src/local-HEAD/pgsql/src/test/regress/./tmp_check/data/base/1 ... TRAP: FailedAssertion(!(rel-rd_rel-relkind == 'r'), File: tuptoaster.c, Line: 440) --- tuptoaster.c13 Oct 2007 22:34:06 +0100 1.78 +++ tuptoaster.c14 Oct 2007 15:37:17 +0100 @@ -437,7 +437,8 @@ * We should only ever be called for tuples of plain relations --- * recursing on a toast rel is bad news. */ - Assert(rel-rd_rel-relkind == RELKIND_RELATION); + Assert(rel-rd_rel-relkind == RELKIND_RELATION || + rel-rd_rel-relkind == RELKIND_UNCATALOGED); /* * Get the tuple descriptor and break down the tuple(s) into fields. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Assertion failure with small block sizes
Gregory Stark [EMAIL PROTECTED] 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
Re: [PATCHES] Assertion failure with small block sizes
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] 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. Well tuptoaster doesn't try to store anything external if there's no toast table anyways. With the assertion modified it passes the regression tests (modulo row orderings). How small is small anyway? This was 1k with 256 toast target/threshold. 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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] Updated patch for tsearch contrib examples
I've reviewed and tested Sergey Karpov's proposed contrib modules dict_int, dict_xsyn, and test_parser. Attached are the updated modules. I have not included the necessary contrib/Makefile and contrib/README additions, nor any patch for the main documentation. I expect we'll just strip out sections 12.9 and 12.10 in favor of referencing the contrib modules. Last call for objections ... regards, tom lane binzCkIEm5xjV.bin Description: ts_examples.tar.gz ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] quote_literal with NULL
On Mon, 2007-10-15 at 12:52 +1000, Brendan Jurd wrote: On 10/12/07, Simon Riggs [EMAIL PROTECTED] wrote: I think you should add some examples to show how we would handle an INSERT or an UPDATE SET with quite_nullable() and a SELECT WHERE clause with quote_literal. The difference is a subtle one, which is why nobody mentioned it before, so it needs some better docs too. A cross-ref to the functions page would help also. Alright, I've improved the documentation along the lines suggested by Simon. There's a full example on doing a null-safe dynamic UPDATE, as well as a brief discussion about being wary of using comparison operators with NULLs (e.g., in WHERE clauses). Cross references abound. Cool I did make a version of the patch which has the pg_proc entries for quote_literal and quote_nullable both pointing to the same internal function. I thought this was a tidier solution, but it failed regression test #5 in opr_sanity; apparently two entries in pg_proc can't have the same prosrc and differing proisstrict? Sanity prevails, I guess. :-) -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] quote_literal with NULL
On 10/15/07, Simon Riggs [EMAIL PROTECTED] wrote: I did make a version of the patch which has the pg_proc entries for quote_literal and quote_nullable both pointing to the same internal function. I thought this was a tidier solution, but it failed regression test #5 in opr_sanity; apparently two entries in pg_proc can't have the same prosrc and differing proisstrict? Sanity prevails, I guess. :-) I'm all for the prevalance of sanity, but I'm not really clear on what about the above scenario is not sane. Suspect I'm missing something about the workings of pg_proc, but from over here it seems like having a strict and a non-strict version of the same function would be okay. As long as the internal function is rigged to handle null input properly, what's the problem? It's only tangential to the patch itself, and I'm not challenging the regression test. Just curious about it. Cheers, BJ ---(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
