Re: pg_dump and write locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David Parker" <dparker(at)tazznetworks(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump and write locks
Date: 2005-07-19 14:44:37
Message-ID: 23835.1121784277@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David Parker" <dparker(at)tazznetworks(dot)com> writes:
> 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.

Are you sure the other processes aren't taking any exclusive locks?
Are you sure your system isn't saturated to the point where pg_dump
just can't make progress very fast?

> 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;

It's impossible to tell what you are actually looking at here --- that's
not the raw output of pg_locks, and you've conveniently omitted any
column headers --- but I wonder whether that isn't just the
transaction's standard lock on its own XID.

If pg_dump is actually getting blocked, that will show as a row with
granted = false and pg_dump's PID.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2005-07-19 14:48:25 Re: index row size exceeds btree maximum, 2713 -
Previous Message Stephan Szabo 2005-07-19 14:37:12 Re: Changes to not deferred FK in 8.0.3 to 7.4?