Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Reviewing freeze map code
Date
Msg-id CA+Tgmoakvdm2DY-RU7SWrXw8+eP5d8bThu=0XqrXfOPts3PwvQ@mail.gmail.com
Whole thread Raw
In response to Re: Reviewing freeze map code  (Andres Freund <andres@anarazel.de>)
Responses Re: Reviewing freeze map code  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Jul 7, 2016 at 1:58 PM, Andres Freund <andres@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 <andres@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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: asynchronous and vectorized execution
Next
From: Robert Haas
Date:
Subject: Re: Issue with bgworker, SPI and pgstat_report_stat