Re: tripping an assert in 8.1.6 (more info) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tripping an assert in 8.1.6 (more info)
Date
Msg-id 5300.1169591248@sss.pgh.pa.us
Whole thread Raw
In response to Re: tripping an assert in 8.1.6 (more info)  (Brian Hurt <bhurt@janestcapital.com>)
Responses Re: tripping an assert in 8.1.6 (more info)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Brian Hurt <bhurt@janestcapital.com> 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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: About PostgreSQL certification
Next
From: "Joshua D. Drake"
Date:
Subject: Re: About PostgreSQL certification