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

Commit ac0e331

Browse files
author
Amit Kapila
committed
Invalidate inactive replication slots.
This commit introduces idle_replication_slot_timeout GUC that allows inactive slots to be invalidated at the time of checkpoint. Because checkpoints happen checkpoint_timeout intervals, there can be some lag between when the idle_replication_slot_timeout was exceeded and when the slot invalidation is triggered at the next checkpoint. To avoid such lags, users can force a checkpoint to promptly invalidate inactive slots. Note that the idle timeout invalidation mechanism is not applicable for slots that do not reserve WAL or for slots on the standby server that are synced from the primary server (i.e., standby slots having 'synced' field 'true'). Synced slots are always considered to be inactive because they don't perform logical decoding to produce changes. The slots can become inactive for a long period if a subscriber is down due to a system error or inaccessible because of network issues. If such a situation persists, it might be more practical to recreate the subscriber rather than attempt to recover the node and wait for it to catch up which could be time-consuming. Then, external tools could create replication slots (e.g., for migrations or upgrades) that may fail to remove them if an error occurs, leaving behind unused slots that take up space and resources. Manually cleaning them up can be tedious and error-prone, and without intervention, these lingering slots can cause unnecessary WAL retention and system bloat. As the duration of idle_replication_slot_timeout is in minutes, any test using that would be time-consuming. We are planning to commit a follow up patch for tests by using the injection point framework. Author: Nisha Moond <nisha.moond412@gmail.com> Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Vignesh C <vignesh21@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Hou Zhijie <houzj.fnst@fujitsu.com> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/CALj2ACW4aUe-_uFQOjdWCEN-xXoLGhmvRFnL8SNw_TZ5nJe+aw@mail.gmail.com Discussion: https://postgr.es/m/OS0PR01MB5716C131A7D80DAE8CB9E88794FC2@OS0PR01MB5716.jpnprd01.prod.outlook.com
1 parent b464e51 commit ac0e331

File tree

15 files changed

+367
-86
lines changed

15 files changed

+367
-86
lines changed

doc/src/sgml/config.sgml

+40
Original file line numberDiff line numberDiff line change
@@ -4429,6 +4429,46 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
44294429
</listitem>
44304430
</varlistentry>
44314431

4432+
<varlistentry id="guc-idle-replication-slot-timeout" xreflabel="idle_replication_slot_timeout">
4433+
<term><varname>idle_replication_slot_timeout</varname> (<type>integer</type>)
4434+
<indexterm>
4435+
<primary><varname>idle_replication_slot_timeout</varname> configuration parameter</primary>
4436+
</indexterm>
4437+
</term>
4438+
<listitem>
4439+
<para>
4440+
Invalidate replication slots that have remained idle longer than this
4441+
duration. If this value is specified without units, it is taken as
4442+
minutes. A value of zero (the default) disables the idle timeout
4443+
invalidation mechanism. This parameter can only be set in the
4444+
<filename>postgresql.conf</filename> file or on the server command
4445+
line.
4446+
</para>
4447+
4448+
<para>
4449+
Slot invalidation due to idle timeout occurs during checkpoint.
4450+
Because checkpoints happen at <varname>checkpoint_timeout</varname>
4451+
intervals, there can be some lag between when the
4452+
<varname>idle_replication_slot_timeout</varname> was exceeded and when
4453+
the slot invalidation is triggered at the next checkpoint.
4454+
To avoid such lags, users can force a checkpoint to promptly invalidate
4455+
inactive slots. The duration of slot inactivity is calculated using the
4456+
slot's <link linkend="view-pg-replication-slots">pg_replication_slots</link>.<structfield>inactive_since</structfield>
4457+
value.
4458+
</para>
4459+
4460+
<para>
4461+
Note that the idle timeout invalidation mechanism is not applicable
4462+
for slots that do not reserve WAL or for slots on the standby server
4463+
that are being synced from the primary server (i.e., standby slots
4464+
having <link linkend="view-pg-replication-slots">pg_replication_slots</link>.<structfield>synced</structfield>
4465+
value <literal>true</literal>). Synced slots are always considered to
4466+
be inactive because they don't perform logical decoding to produce
4467+
changes.
4468+
</para>
4469+
</listitem>
4470+
</varlistentry>
4471+
44324472
<varlistentry id="guc-wal-sender-timeout" xreflabel="wal_sender_timeout">
44334473
<term><varname>wal_sender_timeout</varname> (<type>integer</type>)
44344474
<indexterm>

doc/src/sgml/logical-replication.sgml

+5
Original file line numberDiff line numberDiff line change
@@ -2390,6 +2390,11 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
23902390
plus some reserve for table synchronization.
23912391
</para>
23922392

2393+
<para>
2394+
Logical replication slots are also affected by
2395+
<link linkend="guc-idle-replication-slot-timeout"><varname>idle_replication_slot_timeout</varname></link>.
2396+
</para>
2397+
23932398
<para>
23942399
<link linkend="guc-max-wal-senders"><varname>max_wal_senders</varname></link>
23952400
should be set to at least the same as

doc/src/sgml/system-views.sgml

+7
Original file line numberDiff line numberDiff line change
@@ -2619,6 +2619,13 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
26192619
perform logical decoding. It is set only for logical slots.
26202620
</para>
26212621
</listitem>
2622+
<listitem>
2623+
<para>
2624+
<literal>idle_timeout</literal> means that the slot has remained
2625+
idle longer than the configured
2626+
<xref linkend="guc-idle-replication-slot-timeout"/> duration.
2627+
</para>
2628+
</listitem>
26222629
</itemizedlist>
26232630
</para></entry>
26242631
</row>

src/backend/access/transam/xlog.c

+2-2
Original file line numberDiff line numberDiff line change
@@ -7337,7 +7337,7 @@ CreateCheckPoint(int flags)
73377337
*/
73387338
XLByteToSeg(RedoRecPtr, _logSegNo, wal_segment_size);
73397339
KeepLogSeg(recptr, &_logSegNo);
7340-
if (InvalidateObsoleteReplicationSlots(RS_INVAL_WAL_REMOVED,
7340+
if (InvalidateObsoleteReplicationSlots(RS_INVAL_WAL_REMOVED | RS_INVAL_IDLE_TIMEOUT,
73417341
_logSegNo, InvalidOid,
73427342
InvalidTransactionId))
73437343
{
@@ -7792,7 +7792,7 @@ CreateRestartPoint(int flags)
77927792
replayPtr = GetXLogReplayRecPtr(&replayTLI);
77937793
endptr = (receivePtr < replayPtr) ? replayPtr : receivePtr;
77947794
KeepLogSeg(endptr, &_logSegNo);
7795-
if (InvalidateObsoleteReplicationSlots(RS_INVAL_WAL_REMOVED,
7795+
if (InvalidateObsoleteReplicationSlots(RS_INVAL_WAL_REMOVED | RS_INVAL_IDLE_TIMEOUT,
77967796
_logSegNo, InvalidOid,
77977797
InvalidTransactionId))
77987798
{

0 commit comments

Comments
 (0)