On 24.10.2013 23:07, Josh Berkus wrote:
> On 10/24/2013 11:12 AM, Heikki Linnakangas wrote:
>> On 24.10.2013 20:39, Josh Berkus wrote:
>>> On 10/24/2013 04:15 AM, Pavan Deolasee wrote:
>>>> If we do what you are suggesting, it seems like a single line patch
>>>> to me.
>>>> In XLogSaveBufferForHint(), we probably need to look at this
>>>> additional GUC
>>>> to decide whether or not to backup the block.
>>>
>>> Wait, what? Why are we having an additional GUC?
>>>
>>> I'm opposed to the idea of having a GUC to enable failback. When would
>>> anyone using replication ever want to disable that?
>>
>> For example, if you're not replicating for high availability purposes,
>> but to keep a reporting standby up-to-date.
>
> What kind of overhead are we talking about here? You probably said, but
> I've had a mail client meltdown and lost a lot of my -hackers emails.
One extra WAL record whenever a hint bit is set on a page, for the first
time after a checkpoint. In other words, a WAL record needs to be
written in the same circumstances as with page checksums, but the WAL
records are much smaller as they don't need to contain a full page
image, just the block number of the changed block.
Or maybe we'll write the full page image after all, like with page
checksums, just without calculating the checksums. It might be tricky to
skip the full-page image, because then a subsequent change of the page
(which isn't just a hint-bit update) needs to somehow know it needs to
take a full page image even though a WAL record for it was already written.
- Heikki