Re: AW: AW: Issue NOTICE for attempt to raise lock level?

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

In response to

Browse pgsql-hackers by date

  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