Horton

RE: t/035_standby_logical_decoding.pl might fail on attempt to read wrong timeline

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

View thread View on postgr.es
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Bertrand Drouvot' <bertranddrouvot.pg@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, "xunengzhou@gmail.com" <xunengzhou@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-06-09T07:05:20Z
Lists: pgsql-hackers 
Dear Bertrand,

Thanks for re-posting. Let's focus on the logical decoding stuff.

> > 0004: Add a test for 0003

I found a comment for the test.

```
+# Issue SQL decoding (read_local_xlog_page_guts path) on the pre-connected
+# session.
+$decode_session->query_until(
+       qr/decoding_started/, qq(
+       \\echo decoding_started
+       SELECT count(*) FROM pg_logical_slot_peek_changes('race_slot_sql', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
+));
```

Not sure, pg_logical_slot_peek_changes() can be finished without waiting anything,
right? So why do we use query_until() and check the output here?
IIUC, the command can immediately raise an ERROR if the race happened. So isn't it
enough to use safe_psql() to ensure the SQL function can work?

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Commits

  1. Fix second race with timeline selection during promotion

  2. Remove TAP test for timeline lookup race with logical decoding on standbys

  3. Fix race with timeline selection in logical decoding during promotion

  4. Backport GetWALInsertionTimeLineIfSet()

  5. TAP test for logical decoding on standby