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

Re: pg_dump lock timeout

From: daveg <daveg(at)sonic(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org, hari(at)efrontier(dot)com
Subject: Re: pg_dump lock timeout
Date: 2008-07-22 05:57:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Mon, Jul 21, 2008 at 03:43:11AM -0400, Tom Lane wrote:
> daveg <daveg(at)sonic(dot)net> writes:
> > On Sun, Jul 20, 2008 at 02:50:50PM -0400, Tom Lane wrote:
> >> In most cases our policy has been that pg_dumpall should accept and pass
> >> through any pg_dump option for which it's sensible to do so. I did not
> >> make that happen but it seems it'd be a reasonable follow-on patch.
> > I'll remember that next time.
> Er .. actually that was a direct request for you to do it.

Attached is a the followon patch for pg_dumpall and docs to match pg_dump.

On a second topic, is anyone working on a parallel dump/load? I'd be
interested in helping.


David Gould       daveg(at)sonic(dot)net      510 536 1443    510 282 0869
If simplicity worked, the world would be overrun with insects.

In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2008-07-22 06:33:21
Subject: Re: [WIP] collation support revisited (phase 1)
Previous:From: Matthew T. O'ConnorDate: 2008-07-22 04:31:26
Subject: Re: Concurrent VACUUM and ANALYZE

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-07-22 06:35:30
Subject: Re: pg_dump additional options for performance
Previous:From: Tom LaneDate: 2008-07-21 23:19:46
Subject: Re: pg_dump additional options for performance

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