Re: SyncRepLock acquired exclusively in default configuration

On Fri, 10 Apr 2020 at 13:20, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>
>
>
> On 2020/04/08 3:01, Ashwin Agrawal wrote:
> >
> > On Mon, Apr 6, 2020 at 2:14 PM Andres Freund <andres(at)anarazel(dot)de <mailto:andres(at)anarazel(dot)de>> wrote:
> >
> > > How about we change it to this ?
> >
> > Hm. Better. But I think it might need at least a compiler barrier /
> > volatile memory load? Unlikely here, but otherwise the compiler could
> > theoretically just stash the variable somewhere locally (it's not likely
> > to be a problem because it'd not be long ago that we acquired an lwlock,
> > which is a full barrier).
> >
> >
> > That's the part, I am not fully sure about. But reading the comment above SyncRepUpdateSyncStandbysDefined(), it seems fine.
> >
> > > Bring back the check which existed based on GUC but instead of just blindly
> > > returning based on just GUC not being set, check
> > > WalSndCtl->sync_standbys_defined. Thoughts?
> >
> > Hm. Is there any reason not to just check
> > WalSndCtl->sync_standbys_defined? rather than both !SyncStandbysDefined()
> > and WalSndCtl->sync_standbys_defined?
> >
> >
> > Agree, just checking for WalSndCtl->sync_standbys_defined seems fine.
>
> So the consensus is something like the following? Patch attached.
>
> /*
> - * Fast exit if user has not requested sync replication.
> + * Fast exit if user has not requested sync replication, or there are no
> + * sync replication standby names defined.
> */
> - if (!SyncRepRequested())
> + if (!SyncRepRequested() ||
> + !((volatile WalSndCtlData *) WalSndCtl)->sync_standbys_defined)
> return;
>

I think we need more comments describing why checking
sync_standby_defined without SyncRepLock is safe here. For example:

This routine gets called every commit time. So, to check if the
synchronous standbys is defined as quick as possible we check
WalSndCtl->sync_standbys_defined without acquiring SyncRepLock. Since
we make this test unlocked, there's a change we might fail to notice
that it has been turned off and continue processing. But since the
subsequent check will check it again while holding SyncRepLock, it's
no problem. Similarly even if we fail to notice that it has been
turned on, it's okay to return quickly since all backend consistently
behaves so.

Regards,

--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services