On Wed, Nov 9, 2011 at 10:50 AM, Cédric Villemain <cedric.villemain.deb...@gmail.com> wrote: > 2011/11/9 Robert Haas <robertmh...@gmail.com>: >> On Wed, Nov 9, 2011 at 8:37 AM, Cédric Villemain >> <cedric.villemain.deb...@gmail.com> wrote: >>> Maybe I miss something but: > > I read that the error was produced by first session and didn't check > carefuly (it fails silently in 9.0! and 'works' as expected in 9.1) > > No objection, but I would like to still be able to diagnose the same > things as in the past, can you make it clear that the schema/object > just disappear ? (else we don't know if the relation just never exists > or was drop while we were waiting)
I don't see a clean way to do that, and I'm not convinced it's a good idea anyway. I think that if we start generating different error messages based on whether or not a lock wait was involved at some point in the operation, we're going to drive ourselves nuts. There are a lot of places where that can happen. e.g. Suppose that you have a table with a unique index on column a. Transaction A deletes the tuple where a = 1. Transaction B attempts to insert a new tuple with a = 1, and blocks. Now if A commits, B will succeed, but if A rolls back, B will abort. Had transaction A not existed, B would simply abort at once. But the error message will not indicate which of the two it was, and I don't thinkit needs to. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
