On Fri, Feb 10, 2012 at 10:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Feb 9, 2012 at 6:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Although this is a bug fix, it's a nontrivial change in the logic and
>>> so I'm hesitant to back-patch into stable branches. Given the lack of
>>> prior complaints, maybe it would be best to leave it unfixed in existing
>>> branches? Not sure. Thoughts?
>
>> I guess I'd be in favor of back-patching it, if that doesn't look like
>> too much of a job. We shouldn't assume that because only one person
>> reports a problem, no one else has been or will be affected.
>
> I don't think it's too much work --- what I'm more worried about is
> introducing new bugs. If I apply it only in HEAD then it will go
> through a beta test cycle before anybody relies on it in production.
> I *think* the patch is okay, but I've been wrong before.
Well, I'm not going to second-guess your judgement too much, but my
general feeling is that it's worth taking a bit of risk to get pg_dump
to DTRT. Dump and restore failures are extremely painful and
difficult to work around, so in my book they rank pretty highly in the
list of things that are important to get fixed. So if you're on the
fence, I'd lean toward back-patching.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
