| 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: | Whole Thread | Raw Message | 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
| 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 |