From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: WAL format and API changes (9.5) |
Date: | 2014-11-06 11:23:28 |
Message-ID: | 545B5A30.7070703@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/06/2014 07:57 AM, Amit Kapila wrote:
> On Wed, Nov 5, 2014 at 2:56 PM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2014-11-06 11:41:28 | Re: Typo in comment |
Previous Message | Tomas Vondra | 2014-11-06 11:17:43 | Re: two dimensional statistics in Postgres |