Re: 9a57858f1103b89a5674f0d50c5fe1f756411df6 - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: 9a57858f1103b89a5674f0d50c5fe1f756411df6
Date
Msg-id 20140313013733.GI12995@tamriel.snowman.net
Whole thread Raw
In response to Re: 9a57858f1103b89a5674f0d50c5fe1f756411df6  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 9a57858f1103b89a5674f0d50c5fe1f756411df6  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> This thread badly needs a more informative Subject line.

Agreed.

> But, yeah: do people think the referenced commit fixes a bug bad enough
> to deserve a quick update release?  If so, why?  Multiple reports of
> problems in the field would be a good reason, but I've not seen such.

Uh, isn't what brought this to light two independent complaints from
Peter and Greg Stark of seeing corruption in the field due to this?

Peter's initial email also indicated it was two different systems which
had gotten bit by this and Greg explicitly stated that he was working on
an independent database from what Peter was reporting on, so that's at
least 2 (one each), or 3 (if you count databases, as Peter had 2).
Sure, they're all from Heroku, but I find it highly unlikely no one else
has run into this issue.  More likely, they simply haven't realized it's
happened to them (which is another reason this is a particularly nasty
bug..).

I understand that another release makes work for everyone, and that
stinks, and it's also no fun in the press to have *another* release that
is fixing corruption issues, but sitting on a fix which is actively
causing corruption in the field isn't any good either.

So, my +1 is for a "quick update release"- and if there's a way I can
help offload some of the work (or at least learn the steps to help with
offloading in the future), I'm happy to do so- just let me know.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] Store Extension Options
Next
From: David Johnston
Date:
Subject: Re: Bug: Fix Wal replay of locking an updated tuple (WAS: Re: 9a57858f1103b89a5674f0d50c5fe1f756411df6)