From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Harald Armin Massa" <haraldarminmassa(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: could not open relation - why? |
Date: | 2006-08-07 13:58:26 |
Message-ID: | 20991.1154959106@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Harald Armin Massa" <haraldarminmassa(at)gmail(dot)com> writes:
>> The easiest explanation is that someone dropped a table just as
>> autovacuum was trying to open it.
> I am not quite sure that "autovacuum" was trying to open, as some user
> reported the same error on his system ( and he is definitely not mr.
> Autovacuum :)
Oh, I assumed you had reason to think that the error message came from
autovacuum. It could easily have been the same situation except two
unrelated processes.
> What indeed happens alot in this database is the creation and the dropping
> of temp tables (the later automagically at the end of a connection, I
> assume)
Hmm ... but why would one process be trying to open another one's temp
table? The built-in stuff tries to avoid that, for the most part.
What was that user doing, exactly, when he got the error?
> Is there a way to learn to which dropped table OIDs belong, or is all gone
> after dropping and autovacuum ?
No, not easily --- once the table is dropped the info is gone. You
could try turning on log_error_statement so you could see what SQL
operation is provoking the error; that might help figure it out.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Purser | 2006-08-07 14:11:09 | Re: server optimisation |
Previous Message | Harald Armin Massa | 2006-08-07 13:41:20 | Re: could not open relation - why? |