Re: PG_DUMP and table locking in PG7.4

Поиск
Список
Период
Сортировка
От Yann Michel
Тема Re: PG_DUMP and table locking in PG7.4
Дата
Msg-id 20051116070931.GA6958@zoom.spline.inf.fu-berlin.de
обсуждение исходный текст
Ответ на 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  (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>)
Список 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 по дате отправления:

Предыдущее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: bind variables, soft vs hard parse
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: PG_DUMP and table locking in PG7.4