On Sun, Aug 27, 2017 at 3:34 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sun, Aug 27, 2017 at 12:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> contains exactly no means of ensuring that the master's transaction has >> been replayed on the standby before we check for its results. It's not >> real clear why it seems to work 99.99% of the time, because, well, there >> isn't any frickin' interlock there ... > > I have noticed this one this morning, and I am planning to address it > with a proper patch soonishly. (I am still fighting a bit to get > dangomushi in a more stable stable, and things run slow on it, so it > is good at catching race conditions of this kind).
Today's run has finished with the same failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi&dt=2017-08-27%2018%3A00%3A13 Attached is a patch to make this code path wait that the transaction has been replayed. We could use as well synchronous_commit = apply, but I prefer the solution of this patch with a wait query. -- Michael
tap-2pc-fix.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
