Re: [BUGS] BUG #14721: Assertion of synchronous replication
От
Thomas Munro
Тема
Re: [BUGS] BUG #14721: Assertion of synchronous replication
Дата
Msg-id
CAEepm=33AAJFu9CMPhCsnX-Zg6ZySrga_oAjRV0Dtgx2G03kpQ@mail.gmail.com
Ответ на
Re: [BUGS] BUG #14721: Assertion of synchronous replication (Thomas Munro)
Список
Дерево обсуждения
[BUGS] BUG #14721: Assertion of synchronous replication const_sunny@126.com
Re: [BUGS] BUG #14721: Assertion of synchronous replication Thomas Munro <thomas.munro@enterprisedb.com>
Re: [BUGS] BUG #14721: Assertion of synchronous replication Thomas Munro <thomas.munro@enterprisedb.com>
Re: [BUGS] BUG #14721: Assertion of synchronous replication Heikki Linnakangas <hlinnaka@iki.fi>
On Thu, Jun 29, 2017 at 4:27 PM, Thomas Munro wrote: > /* > * Acquiring the lock is not needed, the latch ensures proper > * barriers. If it looks like we're done, we must really be done, > * because once walsender changes the state to SYNC_REP_WAIT_COMPLETE, > * it will never update it again, so we can't be seeing a stale value > * in that case. > */ Yeah, counting on the latch for free barriers doesn't work if you happen to see SYNC_REP_WAIT_COMPLETE first time through the loop, or if you see it after a spurious signal woke you and then it's immediately set to SYNC_REP_WAIT_COMPLETE. In those cases, the following Assert statement is making an assertion about cache coherency that doesn't work even on a friendly TSO system. Can you reproduce the problem with this experimental patch applied? -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления