Re: SELECT blocking on ALTER TABLE ADD FOREIGN KEY - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: SELECT blocking on ALTER TABLE ADD FOREIGN KEY
Date
Msg-id 20030616061738.GE40542@flake.decibel.org
Whole thread Raw
In response to Re: SELECT blocking on ALTER TABLE ADD FOREIGN KEY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SELECT blocking on ALTER TABLE ADD FOREIGN KEY  (Bruno Wolff III <bruno@wolff.to>)
Re: SELECT blocking on ALTER TABLE ADD FOREIGN KEY  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jun 12, 2003 at 06:23:12PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > Is there any ALTER that would require blocking selects?
> 
> DROP INDEX, for certain.

Sure, but that's usually trivially fast.

> > Even stuff like
> > drop and rename should be protected by versioning, no?
> 
> No.  System-catalog changes are always READ COMMITTED mode.
Yeah, so the catalog changes shouldn't be visible to anyone until after
the ALTER is complete, right? Even if a transaction is set to read
uncommitted, I assume it will always read only committed data from the
catalogs...
-- 
Jim C. Nasby (aka Decibel!)                    jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [GENERAL] UTF8 and KOI8 mini-howto
Next
From: Bruno Wolff III
Date:
Subject: Re: SELECT blocking on ALTER TABLE ADD FOREIGN KEY