Re: [HACKERS] Potential data loss of 2PC files - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Potential data loss of 2PC files
Date
Msg-id CAB7nPqTEYvQUodnu71v=Gsb6sUOmkw90bnF=t7E4FWv5VgwBsQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Potential data loss of 2PC files  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: [HACKERS] Potential data loss of 2PC files
List pgsql-hackers
On Fri, Dec 30, 2016 at 10:59 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
>>
>> Well, flushing the meta-data of pg_twophase is really going to be far
>> cheaper than the many pages done until CheckpointTwoPhase is reached.
>> There should really be a check on serialized_xacts for the
>> non-recovery code path, but considering how cheap that's going to be
>> compared to the rest of the restart point stuff it is not worth the
>> complexity of adding a counter, for example in shared memory with
>> XLogCtl (the counter gets reinitialized at each checkpoint,
>> incremented when replaying a 2PC prepare, decremented with a 2PC
>> commit). So to reduce the backpatch impact I would just do the fsync
>> if (serialized_xact > 0 || RecoveryInProgress()) and call it a day.
>
> Sounds ok to me. I will leave it to the committer to decide further.

Attached is an updated patch. I also noticed that it is better to do
the fsync call before the dtrace call for checkpoint end as well as
logging.
-- 
Michael

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] proposal: session server side variables
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Unusable SP-GiST index