Re: pg_dump and dependencies and --section ... it's a mess - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_dump and dependencies and --section ... it's a mess
Date
Msg-id 4FE3BD0E.8050202@dunslane.net
Whole thread Raw
In response to Re: pg_dump and dependencies and --section ... it's a mess  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump and dependencies and --section ... it's a mess  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 06/21/2012 07:43 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net>  writes:
>> On 06/21/2012 06:25 PM, Tom Lane wrote:
>>> Hm, I guess I've forgotten that one?
>> See<http://archives.postgresql.org/pgsql-hackers/2012-01/msg00561.php>
> I didn't understand that then, and I still don't.  The ALTER TABLE
> CLUSTER might need exclusive lock, but it's not going to hold the lock
> long enough to be an issue.  I could see that there's a problem with
> identify_locking_dependencies believing that two CONSTRAINT items
> conflict (do they really?) but not convinced the CLUSTER aspect has
> anything to do with it.
>
>             

If something else holds a lock on the table (e.g. another CREATE INDEX) 
the ALTER TABLE will block until it's done, waiting for an ACCESS 
EXCLUSIVE lock. The whole method of operation of parallel restore is 
that we are not supposed to start items that might be blocked by 
currently running operations.

cheers

andrew



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [PATCH 04/16] Add embedded list interface (header only)
Next
From: Tom Lane
Date:
Subject: Re: pg_dump and dependencies and --section ... it's a mess