On Tue, Jan 31, 2017 at 3:45 AM, Nikhil Sontakke <nikh...@2ndquadrant.com> wrote: >> --- a/src/backend/access/transam/xlog.c >> +++ b/src/backend/access/transam/xlog.c >> @@ -9573,6 +9573,7 @@ xlog_redo(XLogReaderState *record) >> (errmsg("unexpected timeline ID %u (should be %u) >> in checkpoint record", >> checkPoint.ThisTimeLineID, ThisTimeLineID))); >> >> + KnownPreparedRecreateFiles(checkPoint.redo); >> RecoveryRestartPoint(&checkPoint); >> } >> And actually, when a XLOG_CHECKPOINT_SHUTDOWN record is taken, 2PC >> files are not flushed to disk with this patch. This is a problem as a >> new restart point is created... Having the flush in CheckpointTwoPhase >> really makes the most sense. > > Having CheckPointTwoPhase() do the flush would mean shifting the data > from KnownPreparedList into TwoPhaseState shmem.
Er, no. For CheckPointTwoPhase(), at recovery what needs to be done is to have all the entries in KnownPreparedList() flushed to disk and have those entries removed while holding a shared memory lock. And for the rest we need to be careful to have PrescanPreparedTransactions, RecoverPreparedTransactions and StandbyRecoverPreparedTransactions aware of entries that are in KnownPreparedList(). Let's leave the business of putting the information from KnownPreparedList to TwoPhaseState in RecoverPreparedTransactions, which need to be aware of entries in KnownPreparedList() anyway. The only thing that differs is how the 2PC information is fetched: from the segments or from the files in pg_twophase. > I wonder what's the best location for this in the common case when we > do shutdown of standby. We could add code in XLOG_CHECKPOINT_SHUTDOWN > and XLOG_CHECKPOINT_ONLINE xlog_redo code path. ShutdownXLOG() calls CreateRestartPoint() when a standby shuts down, so doing all the durability work in CheckPointTwoPhase() would take care of any problems. (moving patch to CF 2017-03) -- Michael -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers