On Sat, Dec 31, 2016 at 5:53 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Dec 30, 2016 at 10:59 PM, Ashutosh Bapat > <ashutosh.ba...@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.
The patch looks good to me. I am wondering what happens if a 2PC file gets created, at the time of checkpoint we flush the pg_twophase directory, then the file gets removed. Do we need to flush the directory to ensure that the removal persists? Whatever material I look for fsync() on directory, it gives examples of file creation, not that of deleting a file. If we want to persist the removal, probably we have to flush pg_twophase always or add code to track whether any activity happened in pg_twophase between two checkpoints. The later seems complication not worth the benefit. I guess, it's hard to construct a case to reproduce the issue described in your first mail. But still checking if you have any reproduction. May be we could use similar reproduction to test the deletion of two phase file. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers