Re: [HACKERS] More replication race conditions
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] More replication race conditions |
Дата | |
Msg-id | CAB7nPqTm9p+LCm1mVJYvgpwagRK+uibT-pKq0O2-paOWxT62jw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] More replication race conditions (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] More replication race conditions
Re: [HACKERS] More replication race conditions |
Список | pgsql-hackers |
On Sun, Aug 27, 2017 at 3:34 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Sun, Aug 27, 2017 at 12:03 PM, Tom Lane <tgl@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: