RE: AW: AW: Issue NOTICE for attempt to raise lock leve l?

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 leve l?
Date: 2000-11-07 19:26:57
Message-ID: 8F4C99C66D04D4118F580090272A7A234D314F@sectorbase1.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > 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.

Not only, Tom -:)
Unfortunately, session 3 with just SELECT * FROM foo will also wait
for session 1 & session 2 commit.

Vadim

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2000-11-07 19:30:31 Re: Transaction ID wraparound: problem and proposed solution
Previous Message Jan Wieck 2000-11-07 19:04:11 Re: Unhappy thoughts about pg_dump and objects inherited from template1