Horton

Re: [HACKERS] make async slave to wait for lsn to be replayed

Ivan Kartyshov <i.kartyshov@postgrespro.ru>

View thread View on postgr.es
From: Kartyshov Ivan <i.kartyshov@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Pavel Borisov <pashkin.elfe@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Euler Taveira <euler@eulerto.com>, Thomas Munro <thomas.munro@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, Amit Kapila <amit.kapila16@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Peter Smith <smithpb2250@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-06-12T08:36:05Z
Lists: pgsql-hackers

Attachments

Hi, Alexander, Here, I made some improvements according to your 
discussion with Heikki.

On 2024-04-11 18:09, Alexander Korotkov wrote:
> On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas <hlinnaka@iki.fi> 
> wrote:
>> In a nutshell, it's possible for the loop in WaitForLSN to exit 
>> without
>> cleaning up the process from the heap. I was able to hit that by 
>> adding
>> a delay after the addLSNWaiter() call:
>> 
>> > TRAP: failed Assert("!procInfo->inHeap"), File: "../src/backend/commands/waitlsn.c", Line: 114, PID: 1936152
>> > postgres: heikki postgres [local] CALL(ExceptionalCondition+0xab)[0x55da1f68787b]
>> > postgres: heikki postgres [local] CALL(+0x331ec8)[0x55da1f204ec8]
>> > postgres: heikki postgres [local] CALL(WaitForLSN+0x139)[0x55da1f2052cc]
>> > postgres: heikki postgres [local] CALL(pg_wal_replay_wait+0x18b)[0x55da1f2056e5]
>> > postgres: heikki postgres [local] CALL(ExecuteCallStmt+0x46e)[0x55da1f18031a]
>> > postgres: heikki postgres [local] CALL(standard_ProcessUtility+0x8cf)[0x55da1f4b26c9]
>> 
>> I think there's a similar race condition if the timeout is reached at
>> the same time that the startup process wakes up the process.
> 
> Thank you for catching this.  I think WaitForLSN() just needs to call
> deleteLSNWaiter() unconditionally after exit from the loop.

Fix and add injection point test on this race condition.

> On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas <hlinnaka@iki.fi> 
> wrote:
>> The docs could use some-copy-editing, but just to point out one issue:
>> 
>> > There are also procedures to control the progress of recovery.
>> 
>> That's copy-pasted from an earlier sentence at the table that lists
>> functions like pg_promote(), pg_wal_replay_pause(), and
>> pg_is_wal_replay_paused(). The pg_wal_replay_wait() doesn't control 
>> the
>> progress of recovery like those functions do, it only causes the 
>> calling
>> backend to wait.

Fix documentation and add extra tests on multi-standby replication
and cascade replication.

-- 
Ivan Kartyshov
Postgres Professional: www.postgrespro.com

Commits

  1. Ensure standby promotion point in 043_wal_replay_wait.pl

  2. Minor cleanup related to pg_wal_replay_wait() procedure

  3. Adjust pg_wal_replay_wait() procedure behavior on promoted standby

  4. pg_wal_replay_wait(): Fix typo in the doc

  5. Implement pg_wal_replay_wait() stored procedure

  6. Revert: Implement pg_wal_replay_wait() stored procedure

  7. Call WaitLSNCleanup() in AbortTransaction()

  8. Clarify what is protected by WaitLSNLock

  9. Use an LWLock instead of a spinlock in waitlsn.c

  10. Use the pairing heap instead of a flat array for LSN replay waiters

  11. Minor improvements for waitlsn.c

  12. Make the order of the header file includes consistent