Re: BUG #14721: Assertion of synchronous replication

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>
To: const_sunny@126.com
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Date: 2017-06-29T05:11:47Z
Lists: pgsql-bugs

Attachments

On Thu, Jun 29, 2017 at 4:27 PM, Thomas Munro
<thomas.munro@enterprisedb.com> 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

Commits

  1. Fix ordering of operations in SyncRepWakeQueue to avoid assertion failure.