Re: Reduce SyncRepLock contention on the commit path

Hi Yura,

Thanks for the numbers, backing the series and for the
rebase.

Both code suggestions are great.

v3, on top of your v2, against 9e17d25e79d:

0001
- SyncRepInitWakeList() asserts the list is empty. Nothing between
filling it and draining it can throw today, so this only states
the invariant.
- Latches set front to back. Draining from the end reversed the
release order. Harmless either way; my sense of beauty insisted.

0004
- Accessors renamed SyncRepGetLSN() and SyncRepSetLSN(). The setter
asserts the lock.
- Assert(MyProc->syncRepState == SYNC_REP_NOT_WAITING) moved above the
lock-free exit, which skipped it.
- Comment on lsn[] rewritten: 64-bit atomic read is not a plain
load everywhere. Every access to lsn[] goes through the atomics API
now, including the ones under the lock.

0005 has one real problem. 'standby_1,standby_2' parses as FIRST 1,
so remote_apply waits for standby_1 alone. The test dumps both
standbys and compares them against the primary, taking no wait of its
own. The setval() over pg_sequence right before the dumps is such a
write. Put recovery_min_apply_delay = '10s' on standby_2 and it fails:

ok 10 - compare primary and standby_1 dumps
not ok 11 - compare primary and standby_2 dumps

changed to ANY 2 (standby_1, standby_2) in v3 - remote_apply covers both.
It also exercises the quorum path through SyncRepGetNthLatestSyncRecPtr(),
which 0002 moves out from under the lock

One question in 0005: it runs the whole regression schedule a second
time. Maybe would be behind PG_TEST_EXTRA?

Regards,
Vadim Ponomarev