Re: PG_DUMP and table locking in PG7.4 - Mailing list pgsql-hackers

From Yann Michel
Subject Re: PG_DUMP and table locking in PG7.4
Date
Msg-id 20051116070931.GA6958@zoom.spline.inf.fu-berlin.de
Whole thread Raw
In response to Re: PG_DUMP and table locking in PG7.4  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: PG_DUMP and table locking in PG7.4  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: PG_DUMP and table locking in PG7.4  (Martijn van Oosterhout <kleptog@svana.org>)
Re: PG_DUMP and table locking in PG7.4  (Michael Paesold <mpaesold@gmx.at>)
Re: PG_DUMP and table locking in PG7.4  (Rod Taylor <pg@rbt.ca>)
List pgsql-hackers
Hi,

On Wed, Nov 16, 2005 at 01:25:43PM +0800, Christopher Kings-Lynne wrote:
> I belive a lock is acquired on every table including inherited children 
> BEFORE doing ANY dumping.  To allow pg_dump to get a consistent dump 
> snapshot.

Well, thanks for all the answers. Are the locks then released once they
are not needed any more like in 2PC?
That should still leaqve the taken snapshot of the released table in a
consistent state but might enable other transactions to work on that one
table once it is released. 
I'm asking, because we have a bigger datawarehouse and dump the data for
a backup every night. Unfortunately, the backup now takes realy long.
That means, other processes that insert data will have to wait which is
sometime really long! I was searching for a way to avoid this. I thought
besides the query-speedub we could also gain some benefit for the backup
timing... but it sounds, that this will not automatically help me with
that. :-(

Cheers,
Yann


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: bind variables, soft vs hard parse
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: PG_DUMP and table locking in PG7.4