>>> The xact_redo code will add prepared transactions to the >>> KnownPreparedList in memory. Earlier it used to create the on-disk 2PC >>> file. >>> >>> At standby promote, the surviving (yet uncommitted) prepared >>> transactions from KnownPreparedList need to be persisted, right? >>
>> I don't see why, so please explain or show the error that can be >> caused if we don't. > > I agree with Simon here. There is no point to fsync the 2PC files are > in case of an immediate crash after promotion replay will happen from > the last checkpoint, aka the one before the promotion has been > triggered. So there is no point to flush them at promotion, they would > be replayed anyway. 1) start master 2) start streaming replica 3) on master begin; create table test1(g int); prepare transaction 'test'; 4) Promote standby via trigger file or via "pg_ctl promote" I thought if we don't fsync the KnownPreparedList then we might not create the 2PC state properly on the standby. However, I do realize that we will be calling RecoverPreparedTransactions() eventually on promote. This function will be modified to go through the KnownPreparedList to reload shmem appropriately for 2PC. So, all good in that case. Apologies for the digression. Regards, Nikhils -- Nikhil Sontakke http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
