> 2026年6月8日 19:29，Amit Kapila 写道： > > On Mon, Jun 8, 2026 at 1:27 PM Rui Zhao wrote: >> >> Attaching v2, rebased on top of current master (v1 no longer applied >> cleanly per cfbot). Two improvements were also made since v1: >> >> 1. Test stability >> The TAP test (053_hs_feedback_catalog_xmin.pl) replaced a sleep(2) >> with a poll on pg_stat_replication.reply_time, so it deterministically >> waits for a fresh hot standby feedback round to reach the primary >> instead of relying on wall-clock time. This removes the most obvious >> source of flakiness on slower CI runners. >> >> 2. Performance impact (pgbench) >> I was concerned about adding a UINT32_ACCESS_ONCE(proc->catalog_xmin) >> read and an extra TransactionIdOlder() call per PGPROC iteration in >> ComputeXidHorizons(), which is on a hot path. Measured on a 104-core >> box, scale=30, 64 clients / 32 jobs / 60s, -M prepared, optimized >> build (CFLAGS=-O2, no --enable-cassert): >> >> workload baseline median patched median delta >> ---------------------- --------------- -------------- ----- >> pgbench -S (read-only) 1,596,196 1,617,083 +1.3% >> pgbench (read-write) 129,550 132,024 +1.9% >> >> Numbers are medians of 3 warm runs after a 30s warmup, after I >> discarded the cold-start runs which were dominated by cache priming. >> The patched build comes out marginally above baseline, which is of >> course noise -- adding code does not make things faster -- but it >> confirms the change is below the measurement floor on this hardware. >> Happy to rerun on different shapes (more clients, smaller scale, >> different machine) if anyone wants to see specific numbers. >> >> Summary of the change (unchanged in substance from v1): >> >> - proc.h: add catalog_xmin field to PGPROC (4 bytes) >> - proc.c: initialize it in InitProcess / InitAuxiliaryProcess >> - procarray.c: accumulate proc_catalog_xmin in ComputeXidHorizons() >> and apply it only to catalog_oldest_nonremovable and >> shared_oldest_nonremovable; include it in GetReplicationHorizons() >> so the catalog_xmin propagates correctly in cascading setups >> - walsender.c: in the no-slot path of ProcessStandbyHSFeedbackMessage(), >> set MyProc->xmin and MyProc->catalog_xmin separately instead of >> folding them together >> > > I think storing catalog_xmin separately in PGPROC has few downsides > which are (a) it always needs additional four bytes in PGPROC which is > used for backend and other processes even though it is required for > walsender, (b) as both xmin and catalog_xmin are written separately > ComputeXidHorizons() could read one value as updated and other stale. > There may be something more fundamental which I may be missing but I > feel ephermal slots idea as hinted in comments is worth exploring. > > -- > With Regards, > Amit Kapila.