Re: Avoid full page images in streaming replication? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Avoid full page images in streaming replication?
Date
Msg-id CA+TgmobZUBTYHEeO3sF+=S065iPy4geCu9TuCsokgsfnMNq0aA@mail.gmail.com
Whole thread Raw
In response to Re: Avoid full page images in streaming replication?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Avoid full page images in streaming replication?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Thu, Oct 22, 2015 at 5:57 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> We could in theory send a "this would be been a fpi but it's skipped"
>> record which would only exist in streaming and just make the standby
>> write a noop of some kind? It would still be on the standby but it would
>> at least not consume the bandwidth. Just skip sending the actual
>> contents of the fpi.
>
> I don't think it can be a noop on the receiver though... doesn't the
> receiver still need full page images in case of a crash? (Assuming
> full_page_writes is enabled...)

Yes. If the standby is in the middle of writing a page updated by a
WAL record and crashes, it can end up with a torn page.  We restart
from a restartpoint at a location where the master checkpointed so
that we can be certain that replay of the FPI will fix the problem.
If you got rid of the FPIs, you'd be dead.

This is true both before and after reaching a consistent state, which
seems like a fatal flaw in this plan.

It's true that if the standby didn't have the master's FPIs, it could
generate its own in some side location that behaves like a separate
WAL stream or a double-write buffer.  But that would be a heck of a
lot of work to implement for an uncertain benefit.

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



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [PATCH] SQL function to report log message
Next
From: David Fetter
Date:
Subject: Re: Making tab-complete.c easier to maintain