Hi all,
I spent some extra time walking the code to see where
XactLockTableWait() actually fires.
A condensed recap:
1) Current call-paths
A. Logical walsender (XLogSendLogical → … → SnapBuildWaitSnapshot) in
cascading standby
B. SQL slot functions
(pg_logical_slot_get_changes[_peek])
create_logical_replication_slot
pg_sync_replication_slots
pg_replication_slot_advance
binary_upgrade_logical_slot_has_caught_up
2) How many backends and XIDs in practice
A. Logical walsenders on a cascading standby
One per replication connection, capped by max_wal_senders.
default 10; hubs might run 10–40.
B. Logical slot creation is infrequent and bounded by
max_replication_slots, default 10;
other functions are not called that often either.
C. Wait pattern
XIDs waited-for during a snapshot build: SnapBuildWaitSnapshot wait
for one xid a time;
So, under today’s workloads both the number of xids and waiters stay
modest concurrently.
3) Future growth
Some features could multiply the number of concurrent waiters, but I
don’t have enough knowledge to predict those shapes.
Feedbacks welcome.
Best,
Xuneng
