On 2016-07-07 14:01:05 -0400, Robert Haas wrote: > On Thu, Jul 7, 2016 at 1:58 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2016-07-07 10:37:15 -0400, Robert Haas wrote: > >> On Wed, Jul 6, 2016 at 6:06 PM, Andres Freund <and...@anarazel.de> wrote: > >> > Hm. We can't easily do that in the back-patched version; because a > >> > standby won't know to check for the flag . That's kinda ok, since we > >> > don't yet need to clear all-visible yet at that point of > >> > heap_update. But that better means we don't do so on the master either. > >> > >> Is there any reason to back-patch this in the first place? > > > > It seems not unlikely that this has caused corruption in the past; and > > that we chalked it up to hardware corruption or something. Both toasting > > and file extension frequently take extended amounts of time under load, > > the window for crashing in the wrong moment isn't small... > > Yeah, that's true, but I'm having a bit of trouble imagining exactly > we end up with corruption that actually matters. I guess a torn page > could do it.
I think Noah pointed out a bad scenario: If we crash after putting the xid in the page header, but before WAL logging, the xid could get reused after the crash. By a different transaction. And suddenly the row isn't visible anymore, after the reused xid commits... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
