Re: improving handling of FPIs during recovery prefetching

Hi Shihao,

On 07.11.26 16:08, shihao zhong wrote:
> The updated TAP test addressed your concern. 

Thank you so much for the updated test. I can confirm that the page
image is now part of the actual update. On my system, the test passes
without any errors against the patch series and fails without "Ignore
replayed FPIs in prefetch FPI history".

I think I found a race condition in the TAP test. It executes:

---
$primary->safe_psql('postgres', 'SELECT pg_switch_wal()');
my $end_lsn = $primary->safe_psql('postgres',
'SELECT pg_current_wal_lsn()');
my $walfile = $primary->safe_psql('postgres',
"SELECT pg_walfile_name('$end_lsn'::pg_lsn - 1)");
---

If WAL records are written between pg_switch_wal() and
pg_current_wal_lsn(), $walfile points to a WAL segment that is not
archived, and the test will time out. For example, this could be the
periodically written running_xacts record. I could force this directly
by adding:

---
$primary->safe_psql('postgres',
'SELECT pg_log_standby_snapshot(); SELECT pg_sleep(0.5)');
---

between the two calls, which makes the test die with "timed out waiting
for WAL to be archived".

In 042_low_level_backup.pl, a similar operation is performed, but the
WAL file name is directly taken from the LSN returned by
pg_switch_wal(). What do you think about changing the code in the same
way? With the change below, the test passes even with the injected
pg_log_standby_snapshot() line.

---
my $end_lsn = $primary->safe_psql('postgres', 'SELECT pg_switch_wal()');
my $walfile = $primary->safe_psql('postgres',
"SELECT pg_walfile_name('$end_lsn')");
---

Apart from this, the test looks good to me.

Best regards
Jan

--
Jan Nidzwetzki
PlanetScale