From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> |
Cc: | "'hackers(at)postgresql(dot)org'" <hackers(at)postgresql(dot)org>, "Dr(dot) Michael Meskes" <meskes(at)online-club(dot)de> |
Subject: | Dropping tables... |
Date: | 1998-07-31 16:05:52 |
Message-ID: | 35C1EB60.6C044496@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andreas Zeugswetter wrote:
>
> I would say allow the drop table, of course only if no update or
> intent update (select for update) lock is on it.
> This is how Informix behaves. Otherwise it will become very
> hard to drop tables altogether.
Ok, currently, table can't be dropped if SELECTed by another
running transaction.
Would we like to change this ?!
Comments?
---
Also, I have yet another test for Oracle locking/table
dropping - help me please:
CREATE TABLE test (x integer, y integer);
INSERT INTO test VALUES (1, 1);
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
3. Now again in session T1
DROP TABLE test;
-- will be this blocked ?
TIA,
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 1998-07-31 16:55:25 | Re: [HACKERS] OR clause status report |
Previous Message | Vadim Mikheev | 1998-07-31 15:29:20 | Re: [HACKERS] OR clause status report |