On Wed, Nov 9, 2011 at 10:50 AM, Cédric Villemain
<cedric.villemain.debian@gmail.com> wrote:
> 2011/11/9 Robert Haas <robertmhaas@gmail.com>:
>> On Wed, Nov 9, 2011 at 8:37 AM, Cédric Villemain
>> <cedric.villemain.debian@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