Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group