I ran into the same pg_current_wal_insert_lsn() page-boundary problem discussed in this thread, independently, outside the regression tests, while evaluating WAIT FOR for read-your-writes on a standby using a custom coded application to test the usability of this feature.
At this boundary, pg_current_wal_insert_lsn() returns the next insertion address, which is after the header gap. The test thus waited for a position beyond the existing WAL, requiring another WAL record to make progress. The unrelated progression comes from the primary's background writer who generated a RUNNING_XACTS record, advancing WAL to 0/0301A050, and then notified the waiters.
About 1 in 2000 waits never succeeded and ran to the full TIMEOUT
Since all my sessions were using WAIT FOR LSN, it was a complete stall, whenever it happens.
A client side workaround similar to the following is a temporary solution for me for my tests:
CREATE FUNCTION wal_insert_end_lsn(l pg_lsn DEFAULT pg_current_wal_insert_lsn()) RETURNS pg_lsn LANGUAGE sql STABLE AS $$ SELECT CASE WHEN (l - '0/0'::pg_lsn) % pg_size_bytes(current_setting('wal_segment_size')) < current_setting('wal_block_size')::int -- first page of a segment THEN CASE WHEN (l - '0/0'::pg_lsn) % current_setting('wal_block_size')::int = 40 THEN l - 40 ELSE l END ELSE CASE WHEN (l - '0/0'::pg_lsn) % current_setting('wal_block_size')::int = 24 THEN l - 24 ELSE l END END $$;
A server-side fix would be better
Could WAIT FOR itself also tolerate such targets? When the target points exactly past a page header treat it as the page boundary.
Thanks for tracking this down in the test. It saved me from chasing what looked like a WAIT FOR wakeup bug.
