Re: Potential data loss of 2PC files

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Potential data loss of 2PC files
Date: 2016-12-31 00:23:37
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Fri, Dec 30, 2016 at 10:59 PM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)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

Attachment Content-Type Size
2pc-loss-v2.patch application/stream 800 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-12-31 01:04:37 Re: Unusable SP-GiST index
Previous Message Craig Ringer 2016-12-31 00:16:24 Re: proposal: session server side variables