Re: [HACKERS] Re: Dropping tables... - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] Re: Dropping tables...
Date
Msg-id 35C5519B.CF305216@krs.ru
Whole thread Raw
In response to ...  (Andreas Zeugswetter <andreas.zeugswetter@telecom.at>)
List pgsql-hackers
Thanks again, Michael!

> > 1. In session T1 run
> >
> >    LOCK TABLE test IN EXCLUSIVE MODE;
> >
> > 2. In session T2 run
> >
> >    UPDATE test SET y = 0 WHERE x = 0;
> >
> >    -- shouldn't be blocked by T1 if ROW EXCLUSIVE
> >    -- lock is acquired by T2 only when row found
>
> But it indeed is blocked.

Ok, I misunderstood Oracle documentation..
Blocking means that T2 acquires ROW EXCLUSIVE table lock
_before_ statement execution.

>
> > 3. Now again in session T1
> >
> >    DROP TABLE test;
> >
> >    -- will be this blocked ?
>
> DROP TABLE test
>            *
> ERROR at line 1:
> ORA-00054: resource busy and acquire with NOWAIT specified
>
> However, after this, the update call is executed. After a commit in T2, test
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DROP TABLE commits transaction and releases EXCLUSIVE table lock...

> can be dropped.

No matter was table _really_ modified or not, T2 holds ROW EXCLUSIVE
table lock untill COMMIT/ABORT.

Well...

Vadim

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] TODO item: make pg_shadow updates more robust
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] OR with multi-key indexes