Re: 7.2.3 vacuum bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Rod Taylor <rbt(at)rbt(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.2.3 vacuum bug
Date: 2002-10-31 04:40:05
Message-ID: 3879.1036039205@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil Conway <neilc(at)samurai(dot)com> writes:
> client 1:

> CREATE TABLE a (b int);
> BEGIN;
> DROP TABLE a;
> -- wait

> client 2:

> SELECT * FROM a;

> client 1:

> COMMIT;

> Now, client 2 will receive "RelationClearRelation: relation 25172
> deleted while still in use", rather than "Relation "a" does not
> exist", as you might expect.

But relation "a" *does* exist at the start of client 2's operation.
While I'm not here to defend the exact phrasing of this error message,
it does seem to me that it's appropriate to give a different error
message than what appears when the table wasn't found at all.

An example of why the two cases shouldn't be folded together: suppose
that client 2's schema search path is "myschema, public", and that
client 1 creates/drops myschema.a while there is also a public.a.
client 2 will locate myschema.a as the meaning of "a", and one way or
another it is going to error out when myschema.a gets dropped from
underneath it --- it will not (and shouldn't IMHO) go back and repeat
the schema search to find public.a. But a user who gets a "Relation "a"
does not exist" error message in such a scenario would be justifiably
confused.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-10-31 04:52:28 Re: move 0 behaviour
Previous Message Tom Lane 2002-10-31 04:10:28 Re: PG functions in Java: maybe use gcj?