Re: catalog corruption bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: catalog corruption bug
Date
Msg-id 6616.1136831306@sss.pgh.pa.us
Whole thread Raw
In response to Re: catalog corruption bug  (Jeremy Drake <pgsql@jdrake.com>)
Responses Re: catalog corruption bug  (Jeremy Drake <pgsql@jdrake.com>)
List pgsql-hackers
Jeremy Drake <pgsql@jdrake.com> writes:
> I ran without that function you made, and it got the error, but not a
> crash.  I stuck an Assert(false) right before the ereport for that
> particular error, and I did end up with a core there, but I don't see
> anything out of the ordinary (what little I know of the ordinary ;)

Yeah, that's just the CREATE TEMP TABLE doing what it's supposed to do.
The problem is presumably that a prior DROP operation failed to remove
the pg_type row associated with a previous temp table of the same name
... but why that would happen is still really unclear.

Does your application drop these temp tables explicitly, or leave them
to be dropped automatically during commit?  It might be interesting to
see whether changing that makes any difference.  I'm also curious
whether the transaction that makes the temp table is ever rolled back
instead of committed.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] plpgsql: check domain constraints
Next
From: Thomas Hallgren
Date:
Subject: Re: PLs and domain constraints