Re: Infinite loop in XLogPageRead() on standby

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>

To: michael@paquier.xyz

Cc: cyberdemn@gmail.com, pgsql-hackers@postgresql.org, thomas.munro@gmail.com

Date: 2024-03-01T03:04:31Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix header check for continuation records where standbys could be stuck
- 0f0431e919f4 13.19 landed
- a2d4f806c4b9 14.16 landed
- 26554faccc97 15.11 landed
- 2c2e1d4f42c0 16.7 landed
- e6767c0ed16f 17.3 landed
- 6cf1647d87e7 18.0 landed
Move routines to manipulate WAL into PostgreSQL::Test::Cluster
- c9e50ce2a044 13.19 landed
- 50406b15540c 14.16 landed
- e5d113057d5f 15.11 landed
- 9420f9bb61e6 16.7 landed
- 149ed87e22ce 17.3 landed
- 32a18cc0a73d 18.0 landed
Prevent archive recovery from scanning non-existent WAL files.
- 4bd0ad9e44be 13.0 cited
Fix scenario where streaming standby gets stuck at a continuation record.
- 066871980183 11.0 cited

At Fri, 01 Mar 2024 10:29:12 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> After reading this, I came up with a possibility that walreceiver
> recovers more quickly than the calling interval to
> WaitForWALtoBecomeAvailable(). If walreceiver disconnects after a call
> to the function WaitForWAL...(), and then somehow recovers the
> connection before the next call, the function doesn't notice the
> disconnection and returns XLREAD_SUCCESS wrongly. If this assumption
> is correct, the correct fix might be for us to return XLREAD_FAIL when
> reconnection happens after the last call to the WaitForWAL...()
> function.

That's my stupid. The function performs reconnection by itself.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center