Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit d6e171f

Browse files
committed
Keep replication slot statistics on invalidation
The code path in charge of invalidating a replication slot includes a call to pgstat_drop_replslot(), which would result in removing the statistics of the slot once invalidated. However, there is no need to remove the statistics of an invalidated slot as one could still be interested in looking at them to understand the activity of the slot until its actual removal. The initial design of the feature committed in be87200 used the approach to drop the slots, which is likely why the statistics were still removed during the invalidation. Another problem with this operation is that it was done without holding ReplicationSlotAllocationLock, leaving it unprotected on concurrent activity. This part is arguably a bug, but that's a limited problem in practice so no backpatch is done. In passing, this commit adds a test to check this behavior. The only remaining code path where slot statistics are dropped now related to the slot getting dropped. Author: Bertrand Drouvot Discussion: https://postgr.es/m/ZermH08Eq6YydHpO@ip-10-97-1-34.eu-west-3.compute.internal
1 parent 397cd0b commit d6e171f

File tree

2 files changed

+20
-1
lines changed

2 files changed

+20
-1
lines changed

src/backend/replication/slot.c

-1
Original file line numberDiff line numberDiff line change
@@ -1726,7 +1726,6 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlotInvalidationCause cause,
17261726
ReplicationSlotMarkDirty();
17271727
ReplicationSlotSave();
17281728
ReplicationSlotRelease();
1729-
pgstat_drop_replslot(s);
17301729

17311730
ReportSlotInvalidation(conflict, false, active_pid,
17321731
slotname, restart_lsn,

src/test/recovery/t/035_standby_logical_decoding.pl

+20
Original file line numberDiff line numberDiff line change
@@ -494,6 +494,9 @@ sub wait_until_vacuum_can_remove
494494
##################################################
495495
# Recovery conflict: Invalidate conflicting slots, including in-use slots
496496
# Scenario 1: hot_standby_feedback off and vacuum FULL
497+
#
498+
# In passing, ensure that replication slot stats are not removed when the
499+
# active slot is invalidated.
497500
##################################################
498501

499502
# One way to produce recovery conflict is to create/drop a relation and
@@ -502,6 +505,15 @@ sub wait_until_vacuum_can_remove
502505
reactive_slots_change_hfs_and_wait_for_xmins('behaves_ok_', 'vacuum_full_',
503506
0, 1);
504507

508+
# Ensure that replication slot stats are not empty before triggering the
509+
# conflict.
510+
$node_primary->safe_psql('testdb',
511+
qq[INSERT INTO decoding_test(x,y) SELECT 100,'100';]);
512+
513+
$node_standby->poll_query_until('testdb',
514+
qq[SELECT total_txns > 0 FROM pg_stat_replication_slots WHERE slot_name = 'vacuum_full_activeslot']
515+
) or die "replication slot stats of vacuum_full_activeslot not updated";
516+
505517
# This should trigger the conflict
506518
wait_until_vacuum_can_remove(
507519
'full', 'CREATE TABLE conflict_test(x integer, y text);
@@ -515,6 +527,14 @@ sub wait_until_vacuum_can_remove
515527
# Verify conflict_reason is 'rows_removed' in pg_replication_slots
516528
check_slots_conflict_reason('vacuum_full_', 'rows_removed');
517529

530+
# Ensure that replication slot stats are not removed after invalidation.
531+
is( $node_standby->safe_psql(
532+
'testdb',
533+
qq[SELECT total_txns > 0 FROM pg_stat_replication_slots WHERE slot_name = 'vacuum_full_activeslot']
534+
),
535+
't',
536+
'replication slot stats not removed after invalidation');
537+
518538
$handle =
519539
make_slot_active($node_standby, 'vacuum_full_', 0, \$stdout, \$stderr);
520540

0 commit comments

Comments
 (0)