From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: AW: AW: Issue NOTICE for attempt to raise lock level? |
Date: | 2000-11-07 19:35:45 |
Message-ID: | 14845.973625745@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Tom Lane wrote:
>> I do not believe it is safe to drop read locks intra-transaction, and
>> I am unwilling to take a chance on it being safe so close to 7.1 beta.
> Will we still have readers-dont-block-writers behaviour?
Sure. The only thing this really affects is VACUUM and schema-altering
commands, which will now have to wait until reader transactions commit.
In other words
Session 1 Session 2
BEGIN;
SELECT * FROM foo;
ALTER TABLE foo ...
...
COMMIT;
Session 2 will have to wait for session 1 to commit; before it didn't.
An example of why this is a good idea is
Session 1 Session 2
BEGIN;
DECLARE c CURSOR FOR
SELECT * FROM foo;
ALTER TABLE foo ...
FETCH FROM c;
COMMIT;
Without a held read lock on foo, session 1 is in deep trouble,
because its cursor is no longer correctly planned.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin O'Gorman | 2000-11-07 19:38:40 | Need a debugging tip or two |
Previous Message | Jan Wieck | 2000-11-07 19:30:31 | Re: Transaction ID wraparound: problem and proposed solution |