(unnamed)

text/plain

Download

> 2026年6月8日 19:29，Amit Kapila <amit.kapila16@gmail.com> 写道：
> 
> On Mon, Jun 8, 2026 at 1:27 PM Rui Zhao <zhaorui126@gmail.com> 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.