From: Tom Lane <tgl@sss.pgh.pa.us>
To: Rubén Crespo Flores <ruben.crespo1@gmail.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: Problem creating temporary tables . . .
Date: Thu, 20 Sep 2012 17:04:31 -0400
Message-ID: <15134.1348175071@sss.pgh.pa.us> (raw)
In-Reply-To: <D5173823-CCA8-4323-BBFF-2E493A7B071B@gmail.com>
References: <6F6C406D-518A-4E6F-ACE9-D234B6EB2418@gmail.com>
<11992.1348090218@sss.pgh.pa.us>
<CF523163-E84B-4D07-B98A-2ED5E0DD4E70@gmail.com>
<26932.1348162580@sss.pgh.pa.us>
<D5173823-CCA8-4323-BBFF-2E493A7B071B@gmail.com>
=?iso-8859-1?Q?Rub=E9n_Crespo_Flores?= <ruben.crespo1@gmail.com> writes:
> El 20/09/2012, a las 12:36, Tom Lane escribió:
>> There's something awfully odd about that. A look in the 9.0 sources
>> says that that specific error text only appears in RemoveAttrDefault
>> and getObjectDescription - and the latter is only used in error
>> messages. It's not apparent why a CREATE TABLE operation would either
>> be dropping column defaults or issuing error messages that cite an
>> already-existing default. Could you show a complete example of this
>> behavior?
> Here is an example :
Hmm ... unsurprisingly, this doesn't fail for me. I also tried setting
debugger breakpoints at the two places where the message could be
generated, and neither of them are ever reached while running this
function. So something's pretty broken at your end.
After thinking for awhile, though, I do have a theory, and it squares
with your observation that you need to open a lot of connections to see
the problem. I think that there's a broken partial table definition in
a high-numbered pg_temp_nnn schema. When a new session first tries to
use a temp table, it either creates or cleans out the pg_temp_nnn schema
corresponding to its session number. If some previous user of that
schema had left it not-cleaned-out as a result of crashing, that would
result in table drop attempts, and from there it's not hard to see why
you'd get to RemoveAttrDefault. If things are sufficiently confused
this could end up trying to remove column defaults that aren't there.
What I'd suggest doing is looking in pg_depend for the row with classid
= 2604 and objid = 259154466, and manually removing that row. That
should let the schema drop get past this problem. There might be some
more, similar, problems.
Also, it'd probably be a smart thing to reindex pg_depend, just in case
this isn't a data problem but an index problem.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, ruben.crespo1@gmail.com
Subject: Re: Problem creating temporary tables . . .
In-Reply-To: <15134.1348175071@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox