Re: WAL format and API changes (9.5)

On 11/06/2014 07:57 AM, Amit Kapila wrote:
> On Wed, Nov 5, 2014 at 2:56 PM, Heikki Linnakangas <hlinnakangas@vmware.com>
> wrote:
>> On 11/05/2014 09:06 AM, Amit Kapila wrote:
>>>
>>> 2.
>>> XLogRecPtr
>>> XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn)
>>
>> So the scenario is that:
>>
>> * XLogRecordAssemble decides that a page doesn't need to be backed up
>> * both RedoRecPtr and doPageWrites change while building the record.
>> doPageWrites goes from true to false.
>>
>> Without the patch, we would retry, because first check RedoRecPtr has
>> changed. With the patch, we notice that even though RedoRecPtr has changed,
>> doPageWrites is now off, so no FPWs are required regardless of RedoRecPtr,
>> and not retry. Yeah, you're right, the behavior changes in that case.
>> However, the new behavior is correct; the retry is unnecessary in that
>> scenario.
>
> How does it interact with backup, basically in stop backup we first
> change forcePageWrite to false and then get the stop wal location
> by inserting XLOG_BACKUP_END, so it seems to me that it is quite
> possible that the record which backend is inserting using XLogInsert()
> will be considered in backup.  Now shouldn't this record contain FPW
> if forcePageWrite was true when XLogInsert() started to avoid any torn
> page taken in backup?

It doesn't matter what doPageWrites and RedoRecPtr were when XLogInsert 
started. It's the state when the insertion actually happens that matters.

It's a bit weird that pg_stop_backup() first turns off forcePagesWrites, 
and only then writes the WAL record. But it's OK because when 
pg_stop_backup() is called, the backup process has already finished 
copying all the blocks. Any pages that are written to disk between 
turning forcePageWrites off and writing the WAL record cannot be torn.

- Heikki