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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-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.

Attachment Content-Type Size
pg-dumpall-timeout.patch text/plain 2.4 KB

In response to


Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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