[HACKERS] tripping an assert in 8.1.6
Hello all. It seems I'm tripping an assert in 8.1.6- the assert on line 219 of src/backend/executor/execScan.c (found by running gdb on a core dump). This is on x86 and Redhat Linux (forget which version). Note that if I recompile 8.1.6 with asserts turned off the query completes just fine. I'm trying to put together an example which reproduces the problem without requiring half our company's data- that should follow soon. The gdb backtrace is: #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7d2dee9 in raise () from /lib/libc.so.6 #2 0xb7d2f4f1 in abort () from /lib/libc.so.6 #3 0x0824f931 in ExceptionalCondition (conditionName=Variable conditionName is not available. ) at assert.c:51 #4 0x081537ac in ExecAssignScanProjectionInfo (node=0x8426bec) at execScan.c:219 #5 0x08161339 in ExecInitSubqueryScan (node=0x8412de4, estate=0x8426ad4) at nodeSubqueryscan.c:212 #6 0x0814e0e4 in ExecInitNode (node=0x8412de4, estate=0x8426ad4) at execProcnode.c:179 #7 0x0814c554 in ExecutorStart (queryDesc=0x842554c, explainOnly=1 '\001') at execMain.c:618 #8 0x081193f5 in ExplainOnePlan (queryDesc=0x842554c, stmt=0x839afe4, tstate=0x83cbdac) at explain.c:243 #9 0x081198ac in ExplainOneQuery (query=0x83b88e4, stmt=0x839afe4, tstate=0x83cbdac) at explain.c:214 #10 0x08119a92 in ExplainQuery (stmt=0x839afe4, dest=0x83b8a54) at explain.c:121 #11 0x081da391 in PortalRunUtility (portal=0x83b67b4, query=0x839b07c, dest=0x83b8a54, completionTag=0x0) at pquery.c:987 #12 0x081db6dc in PortalRun (portal=0x83b67b4, count=2147483647, dest=0x839b030, altdest=0x839b030, completionTag=0xbf9efee8 ) at pquery.c:637 #13 0x081d713c in exec_simple_query ( query_string=0x839a26c explain SELECT action, bloomberg_code, composite_bloomberg_code, reuters_code, cusip_code, sedol_code, isin_code FROM vw_ca_generic_actions WHERE (action_date = '20070122'::date) AND (action_date = ...) at postgres.c:1004 #14 0x081d8bd3 in PostgresMain (argc=4, argv=0x83593f0, username=0x83593b8 postgres) at postgres.c:3232 #15 0x081aca37 in ServerLoop () at postmaster.c:2865 #16 0x081ad936 in PostmasterMain (argc=3, argv=0x8358560) at postmaster.c:941 #17 0x0816c1c9 in main (argc=3, argv=Cannot access memory at address 0x1515 ) at main.c:265 This is mainly a heads up- bug incomming message. Thanks. Brian ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] tripping an assert in 8.1.6 (more info)
More info on that assert I've hit.
Compile 8.1.6 with configuration options:
./configure --with-perl --enable-debug --enable-cassert
(not sure if --perl is relevent or not, I think not).
This is on Fedora Core 5 on x86-32.
Execute, on a fresh database, the following sql, to recreate the bug:
CREATE TABLE foo
(
some_data VARCHAR(32)
,row_date DATE
);
CREATE TABLE bar
(
some_data VARCHAR(32)
,row_date DATE
);
CREATE TABLE quux
(
some_data VARCHAR(32)
,more_data VARCHAR(32)
);
CREATE OR REPLACE VIEW bazz AS
SELECT
('bar: ' || bar.row_date) :: TEXT AS action,
quux.more_data AS more_data,
bar.row_date AS row_date
FROM
bar
JOIN quux
ON bar.some_data = quux.some_data
UNION ALL
SELECT
('foo: ' || foo.row_date) :: TEXT AS action,
quux.more_data AS more_data,
foo.row_date AS row_date
FROM
foo
JOIN quux
ON foo.some_data = quux.some_data
;
SELECT action, more_data FROM bazz;
---(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: [HACKERS] tripping an assert in 8.1.6 (more info)
I forgot to mention: core dumps available upon request (obviously I don't want to post them to the list). Brian ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] tripping an assert in 8.1.6 (more info)
Brian Hurt [EMAIL PROTECTED] writes: Execute, on a fresh database, the following sql, to recreate the bug: Hmm, I thought that stack trace looked a bit familiar --- we seem to have fixed the problem as of 8.2. Unfortunately I can't recall what the relevant change was exactly; time for some digging in the CVS logs. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] tripping an assert in 8.1.6 (more info)
Tom Lane wrote: Brian Hurt [EMAIL PROTECTED] writes: Execute, on a fresh database, the following sql, to recreate the bug: Hmm, I thought that stack trace looked a bit familiar --- we seem to have fixed the problem as of 8.2. Unfortunately I can't recall what the relevant change was exactly; time for some digging in the CVS logs. Any hope of getting the fix back-ported into the 8.1 tree? Brian
Re: [HACKERS] tripping an assert in 8.1.6 (more info)
Brian Hurt [EMAIL PROTECTED] writes: Tom Lane wrote: Hmm, I thought that stack trace looked a bit familiar --- we seem to have fixed the problem as of 8.2. Unfortunately I can't recall what the relevant change was exactly; time for some digging in the CVS logs. Any hope of getting the fix back-ported into the 8.1 tree? The bug I was remembering is this one: http://archives.postgresql.org/pgsql-hackers/2006-12/msg00313.php http://archives.postgresql.org/pgsql-committers/2006-12/msg00055.php which happens to fail at the same place but the cause is quite different --- the fix was in code that didn't even exist in 8.1. What seems to be happening here is that since 8.1 did not try to track typmod in UNION trees, the view's column is declared as having type varchar with typmod -1, and so the upper-level Var for the column has that too. But because 8.1 strips out unnecessary SubqueryScan nodes, that Var ends up just one level above the outputs of the MergeJoins, which show the correct typmod from the underlying tables. So that Assert gets upset. (You don't see the bug in 8.0 because it didn't have that optimization.) I'm tempted to suggest that we just remove the Assert on vartypmod in the 8.1 branch. The Assert on vartype is doing as much as is really important to check, and I don't want to disable the trivial_subqueryscan optimization, which seems the only other low-risk fix. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] tripping an assert in 8.1.6 (more info)
I wrote:
I'm tempted to suggest that we just remove the Assert on vartypmod in
the 8.1 branch. The Assert on vartype is doing as much as is really
important to check, and I don't want to disable the trivial_subqueryscan
optimization, which seems the only other low-risk fix.
After further thought I've developed a modified version of Brian's case
that crashes 8.2 and HEAD but not 8.1 --- it turns the situation around
by having the view fall back to typmod -1. So what I'm now thinking
is that the real problem is that an Append path generates its Vars by
copying the first input, and in these sorts of situations that might not
produce the correct typmod. Back to the drawing board ...
regards, tom lane
CREATE TABLE foo
(
x_data varchar(32),
row_date date
);
CREATE TABLE bar
(
x_data varchar(36),
row_date date
);
CREATE OR REPLACE VIEW bazz AS
SELECT
('bar: ' || bar.row_date) :: TEXT AS action,
bar.x_data AS more_data,
row_date
FROM
bar
UNION ALL
SELECT
('foo: ' || foo.row_date) :: TEXT AS action,
foo.x_data AS more_data,
row_date
FROM
foo
;
SELECT action, more_data FROM bazz;
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] tripping an assert in 8.1.6 (more info)
I wrote: After further thought I've developed a modified version of Brian's case that crashes 8.2 and HEAD but not 8.1 --- it turns the situation around by having the view fall back to typmod -1. So what I'm now thinking is that the real problem is that an Append path generates its Vars by copying the first input, and in these sorts of situations that might not produce the correct typmod. Back to the drawing board ... Nope, that's not right either. What it seems to boil down to is what I said the first time: removal of trivial subqueryscans can leave us with a plan that uses an above-a-union Var to describe a value from one of the union inputs. Some other 8.2 changes moved the subqueryscans around, which is why the cases that manifest are a bit different, but in the end it's the same issue. I've concluded that this isn't really wrong; it's certainly not worth disabling the trivial-subqueryscan optimization for, and I think getting the planner to avoid the problem without that would be tricky. Accordingly, I've applied the attached patch that just relaxes the Assert. regards, tom lane Index: execScan.c === RCS file: /cvsroot/pgsql/src/backend/executor/execScan.c,v retrieving revision 1.39 diff -c -r1.39 execScan.c *** execScan.c 5 Jan 2007 22:19:27 - 1.39 --- execScan.c 24 Jan 2007 01:03:03 - *** *** 215,222 return false; /* out of order */ if (att_tup-attisdropped) return false; /* table contains dropped columns */ Assert(var-vartype == att_tup-atttypid); ! Assert(var-vartypmod == att_tup-atttypmod); tlist_item = lnext(tlist_item); } --- 215,232 return false; /* out of order */ if (att_tup-attisdropped) return false; /* table contains dropped columns */ + /* +* Note: usually the Var's type should match the tupdesc exactly, +* but in situations involving unions of columns that have different +* typmods, the Var may have come from above the union and hence have +* typmod -1. This is a legitimate situation since the Var still +* describes the column, just not as exactly as the tupdesc does. +* We could change the planner to prevent it, but it'd then insert +* projection steps just to convert from specific typmod to typmod -1, +* which is pretty silly. +*/ Assert(var-vartype == att_tup-atttypid); ! Assert(var-vartypmod == att_tup-atttypmod || var-vartypmod == -1); tlist_item = lnext(tlist_item); } ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
