From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | daveg <daveg(at)sonic(dot)net> |
Cc: | pgsql-patches(at)postgresql(dot)org, hari(at)efrontier(dot)com |
Subject: | Re: pg_dump lock timeout |
Date: | 2008-07-20 18:50:50 |
Message-ID: | 13580.1216579850@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
daveg <daveg(at)sonic(dot)net> writes:
> Here is an updated version of this patch against head. It builds, runs and
> functions as expected. I did not build the sgml.
Applied with mostly minor cosmetic improvements --- the only actual
error I noticed was failing to check whether the server version supports
statement_timeout.
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.
A minor point is that the syntax "-X lock-wait-timeout=n" or
"-X lock-wait-timeout n" won't work, although perhaps people used to
-X might expect it to. Since we deprecate -X (and don't even document
it anymore), I thought that making this work would be much more trouble
than it's worth, but perhaps that's open to argument.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-20 19:05:27 | Re: CommitFest dragging? |
Previous Message | Joshua D. Drake | 2008-07-20 17:22:22 | Re: CommitFest dragging? |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2008-07-20 21:43:35 | Re: pg_dump additional options for performance |
Previous Message | Tom Lane | 2008-07-20 16:22:30 | Re: [PATCHES] WITH RECUSIVE patches 0717 |