Re: pg_dumpall blocking other sessions

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Terry Schmitt <tschmitt(at)schmittworks(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: pg_dumpall blocking other sessions
Date: 2010-09-30 17:11:55
Message-ID: 4CA4C4DB.50609@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Le 30/09/2010 17:50, Terry Schmitt a écrit :
> [...]
> I had a situation where a session was getting blocked while per
> performing a pg_dumpall.
>
> I could see the pg_dumpall session executing a COPY command on a table
> in one schema.
> Another user session was attempting to truncate a different table in a
> different schema, but in the same database. This session was being
> blocked by the pg_dumpall session.
>
> I intend to test this further, but my understanding was that pg_dump
> was a non-blocking operation. I'm still on the learning curve with
> Postgres 8.4 (actually EnterpriseDB Advanced Server), so maybe I just
> need more detail on how pg_dumpall works.
> Is the truncate perhaps the problem, but other dml is allowed?
>

There's a light lock held on every objects so that pg_dump/pg_dumpall
can save every object existing at the time it was fired. This light lock
doesn't allow one to drop or truncate a table because these operations
require exclusive access to the table (which they can't have since
pg_dump/pg_dumpall have a light lock on it). But you can still insert,
update, delete (even all) lines in every table.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Greg Smith 2010-09-30 23:38:21 Re: could not connect to server: Connection refused (0x0000274D/10061)
Previous Message Terry Schmitt 2010-09-30 15:50:10 pg_dumpall blocking other sessions