From: | "David Parker" <dparker(at)tazznetworks(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | pg_dump and write locks |
Date: | 2005-07-19 13:51:50 |
Message-ID: | 07FDEE0ED7455A48AC42AC2070EDFF7C8E3FBE@corpsrv2.tazznetworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
We have an issue with running pg_dump while a database is under
reasonably heavy update load. This is 7.4.5 on Solaris 9/intel.
The observed behavior was that a pg_dump running with nothing else going
on takes a couple of minutes, but when we are running some system tests
that do heavy updates to a selection of application tables, it appears
that pg_dump blocks until the update run is done. This didn't make sense
because everything I can find about pg_dump indicates that it should
only be taking read locks, so I don't see why it should be blocked.
We looked at pg_locks, and saw that the pg_dump process was acquiring
locks like:
14764 | ExclusiveLock | 124576072 | COPY public.stats (id,
description, lastsavedate, lastsaveuser) TO stdout;
(we are using pg_dump with -Fc) If COPY is taking a ROW EXCLUSIVE lock,
then that would explain why we are seeing contention, but I don't
understand why COPY is locking at that level. Is there a better way to
run pg_dump against a database with a lot of update activity?
Thanks.
- DAP
======================================================
David Parker Tazz Networks
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-19 14:05:43 | Re: dump/restore needed when switching from 32bit to 64bit processor architecture? |
Previous Message | Tom Lane | 2005-07-19 13:40:18 | Re: Changes to not deferred FK in 8.0.3 to 7.4? |