Skip site navigation (1) Skip section navigation (2)

Re: speeding up pg_dump?

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: speeding up pg_dump?
Date: 2005-12-28 04:51:02
Message-ID: m3k6dpq0y1.fsf@mobile.int.cbbrowne.com (view raw or flat)
Thread:
Lists: pgsql-novice
> From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> Every transaction takes ExclusiveLock on its own transaction ID.  That
>> in itself isn't an issue.  You sure you don't see any rows with granted
>> = 'f' while pg_dump is running and everything seems blocked?
>
> yes. during a pg_dump, there are like 30 locks - all of then granted (t)

That makes sense; once you are dumping the 30th table, there will be
about 30 locks, although they should only be AccessShared locks.

> i'll set up pg8.1.1 tomorrow on a new server to check if its db/web or
> server related...

You can expect to see a bunch of AccessShared locks associated with
the transaction used for the pg_dump.

The interesting question is what *else* is trying to grab a lock; that
"something else" is presumably the root of your troubles.
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxfinances.info/info/slony.html
Keeping instructions  and operands  in  different memories  saves  .20
(.09) microseconds.

In response to

pgsql-novice by date

Next:From: Kevin CrenshawDate: 2005-12-28 12:15:36
Subject: Re: Complex Query Help- For Me, Anyway
Previous:From: Yumiko IzumiDate: 2005-12-28 02:43:05
Subject: We want to monitor total size of database

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group