pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedUnexpected behavior when setting "idle_replication_slot_timeout"
38+ messages / 8 participants
[nested] [flat]
* Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-04 09:54 Gunnar Morling <gunnar.morling@googlemail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Gunnar Morling @ 2025-07-04 09:54 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org
Hi all,
I am exploring the new setting "idle_replication_slot_timeout" in Postgres
18; for testing purposes, I set the value to "30s", which, unexpectedly to
me, didn't cause an idle slot to be invalidated when I triggered a
checkpoint after the timeout had been reached.
The docs of the option state that the value is rounded up or down to the
nearest full minute, so I reckon "30s" gets rounded down to 0, thus
effectively disabling the feature. It might be less surprising to users if
values between "1s" and "59s" get actually always rounded up to one minute?
Arguably, that'd seem the more intuitive behavior to me. Alternatively,
logging a warning might be considered for values between "1s" and "30s"?
Curious what folks here think.
Thanks and all the best,
--Gunnar
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-04 12:14 Nisha Moond <nisha.moond412@gmail.com>
parent: Gunnar Morling <gunnar.morling@googlemail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Nisha Moond @ 2025-07-04 12:14 UTC (permalink / raw)
To: Gunnar Morling <gunnar.morling@googlemail.com>; +Cc: pgsql-bugs@lists.postgresql.org
On Fri, Jul 4, 2025 at 4:35 PM Gunnar Morling
<gunnar.morling@googlemail.com> wrote:
>
> Hi all,
>
> I am exploring the new setting "idle_replication_slot_timeout" in Postgres 18; for testing purposes, I set the value to "30s", which, unexpectedly to me, didn't cause an idle slot to be invalidated when I triggered a checkpoint after the timeout had been reached.
>
> The docs of the option state that the value is rounded up or down to the nearest full minute, so I reckon "30s" gets rounded down to 0, thus effectively disabling the feature. It might be less surprising to users if values between "1s" and "59s" get actually always rounded up to one minute? Arguably, that'd seem the more intuitive behavior to me. Alternatively, logging a warning might be considered for values between "1s" and "30s"? Curious what folks here think.
>
Thanks for bringing this up!
Yes, this is expected behavior, idle_replication_slot_timeout accepts
values in minutes, so a setting like "30s" is rounded down to 0,
effectively disabling the timeout, while values >= "31s" are rounded
up to 1.
This behavior isn’t specific to this GUC as Postgres generally rounds
values below a parameter’s minimum unit without a warning. For
example, wal_summary_keep_time and log_rotation_age behave the same
way.
--
Thanks,
Nisha
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-04 14:12 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Nisha Moond <nisha.moond412@gmail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Fujii Masao @ 2025-07-04 14:12 UTC (permalink / raw)
To: Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; +Cc: pgsql-bugs@lists.postgresql.org
On 2025/07/04 21:14, Nisha Moond wrote:
> On Fri, Jul 4, 2025 at 4:35 PM Gunnar Morling
> <gunnar.morling@googlemail.com> wrote:
>>
>> Hi all,
>>
>> I am exploring the new setting "idle_replication_slot_timeout" in Postgres 18; for testing purposes, I set the value to "30s", which, unexpectedly to me, didn't cause an idle slot to be invalidated when I triggered a checkpoint after the timeout had been reached.
>>
>> The docs of the option state that the value is rounded up or down to the nearest full minute, so I reckon "30s" gets rounded down to 0, thus effectively disabling the feature.
When I first tried using idle_replication_slot_timeout, I also encountered this issue.
> It might be less surprising to users if values between "1s" and "59s" get actually always rounded up to one minute? Arguably, that'd seem the more intuitive behavior to me. Alternatively, logging a warning might be considered for values between "1s" and "30s"? Curious what folks here think.
>>
>
> Thanks for bringing this up!
>
> Yes, this is expected behavior, idle_replication_slot_timeout accepts
> values in minutes, so a setting like "30s" is rounded down to 0,
> effectively disabling the timeout, while values >= "31s" are rounded
> up to 1.
>
> This behavior isn’t specific to this GUC as Postgres generally rounds
> values below a parameter’s minimum unit without a warning. For
> example, wal_summary_keep_time and log_rotation_age behave the same
> way.
Right.
But I wonder why the current unit of this GUC is minutes (GUC_UNIT_MIN).
Since at least two users (including myself) tried to set it to a value
less than 1 minute, it might worth considering changing the unit to seconds
(GUC_UNIT_S). Also which would reduces the chance of the reported trouble.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-04 15:22 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 38+ messages in thread
From: Fujii Masao @ 2025-07-04 15:22 UTC (permalink / raw)
To: Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; +Cc: pgsql-bugs@lists.postgresql.org
On 2025/07/04 23:12, Fujii Masao wrote:
> But I wonder why the current unit of this GUC is minutes (GUC_UNIT_MIN).
> Since at least two users (including myself) tried to set it to a value
> less than 1 minute, it might worth considering changing the unit to seconds
> (GUC_UNIT_S). Also which would reduces the chance of the reported trouble.
Attached patch changes unit of idle_replication_slot_timeout to seconds.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From d7e528c1adaf517b86ef97454c80d369f7c9f23a Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Fri, 4 Jul 2025 23:39:48 +0900
Subject: [PATCH v1] Change unit of idle_replication_slot_timeout to seconds.
Previously, idle_replication_slot_timeout was measured in minutes.
This commit changes the unit to seconds, allowing finer-grained
timeout settings.
---
doc/src/sgml/config.sgml | 2 +-
src/backend/replication/slot.c | 15 ++++++---------
src/backend/utils/misc/guc_tables.c | 6 +++---
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/include/replication/slot.h | 2 +-
5 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 59a0874528a..bd12225cbe4 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4620,7 +4620,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
<para>
Invalidate replication slots that have remained idle longer than this
duration. If this value is specified without units, it is taken as
- minutes. A value of zero (the default) disables the idle timeout
+ seconds. A value of zero (the default) disables the idle timeout
invalidation mechanism. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command
line.
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index f9fec50ae88..a6512034ba7 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -154,7 +154,7 @@ int max_replication_slots = 10; /* the maximum number of replication
* Invalidate replication slots that have remained idle longer than this
* duration; '0' disables it.
*/
-int idle_replication_slot_timeout_mins = 0;
+int idle_replication_slot_timeout_secs = 0;
/*
* This GUC lists streaming replication standby server slot names that
@@ -1612,13 +1612,10 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
case RS_INVAL_IDLE_TIMEOUT:
{
- int minutes = slot_idle_seconds / SECS_PER_MINUTE;
- int secs = slot_idle_seconds % SECS_PER_MINUTE;
-
/* translator: %s is a GUC variable name */
- appendStringInfo(&err_detail, _("The slot's idle time of %dmin %02ds exceeds the configured \"%s\" duration of %dmin."),
- minutes, secs, "idle_replication_slot_timeout",
- idle_replication_slot_timeout_mins);
+ appendStringInfo(&err_detail, _("The slot's idle time of %lds exceeds the configured \"%s\" duration of %ds."),
+ slot_idle_seconds, "idle_replication_slot_timeout",
+ idle_replication_slot_timeout_secs);
/* translator: %s is a GUC variable name */
appendStringInfo(&err_hint, _("You might need to increase \"%s\"."),
"idle_replication_slot_timeout");
@@ -1656,7 +1653,7 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
static inline bool
CanInvalidateIdleSlot(ReplicationSlot *s)
{
- return (idle_replication_slot_timeout_mins != 0 &&
+ return (idle_replication_slot_timeout_secs != 0 &&
!XLogRecPtrIsInvalid(s->data.restart_lsn) &&
s->inactive_since > 0 &&
!(RecoveryInProgress() && s->data.synced));
@@ -1734,7 +1731,7 @@ DetermineSlotInvalidationCause(uint32 possible_causes, ReplicationSlot *s,
* idle_replication_slot_timeout GUC.
*/
if (TimestampDifferenceExceedsSeconds(s->inactive_since, now,
- idle_replication_slot_timeout_mins * SECS_PER_MINUTE))
+ idle_replication_slot_timeout_secs))
{
*inactive_since = s->inactive_since;
return RS_INVAL_IDLE_TIMEOUT;
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 511dc32d519..a925be86944 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -3100,10 +3100,10 @@ struct config_int ConfigureNamesInt[] =
gettext_noop("Sets the duration a replication slot can remain idle before "
"it is invalidated."),
NULL,
- GUC_UNIT_MIN
+ GUC_UNIT_S
},
- &idle_replication_slot_timeout_mins,
- 0, 0, INT_MAX / SECS_PER_MINUTE,
+ &idle_replication_slot_timeout_secs,
+ 0, 0, INT_MAX,
check_idle_replication_slot_timeout, NULL, NULL
},
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 341f88adc87..a9d8293474a 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -342,7 +342,7 @@
# (change requires restart)
#wal_keep_size = 0 # in megabytes; 0 disables
#max_slot_wal_keep_size = -1 # in megabytes; -1 disables
-#idle_replication_slot_timeout = 0 # in minutes; 0 disables
+#idle_replication_slot_timeout = 0 # in seconds; 0 disables
#wal_sender_timeout = 60s # in milliseconds; 0 disables
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
diff --git a/src/include/replication/slot.h b/src/include/replication/slot.h
index ffacba9d2ae..76aeeb92242 100644
--- a/src/include/replication/slot.h
+++ b/src/include/replication/slot.h
@@ -266,7 +266,7 @@ extern PGDLLIMPORT ReplicationSlot *MyReplicationSlot;
/* GUCs */
extern PGDLLIMPORT int max_replication_slots;
extern PGDLLIMPORT char *synchronized_standby_slots;
-extern PGDLLIMPORT int idle_replication_slot_timeout_mins;
+extern PGDLLIMPORT int idle_replication_slot_timeout_secs;
/* shmem initialization functions */
extern Size ReplicationSlotsShmemSize(void);
--
2.49.0
Attachments:
[text/plain] v1-0001-Change-unit-of-idle_replication_slot_timeout-to-s.patch (5.5K, ../../b26f13d7-769a-4b64-8bed-cb3a833c0604@oss.nttdata.com/2-v1-0001-Change-unit-of-idle_replication_slot_timeout-to-s.patch)
download | inline diff:
From d7e528c1adaf517b86ef97454c80d369f7c9f23a Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Fri, 4 Jul 2025 23:39:48 +0900
Subject: [PATCH v1] Change unit of idle_replication_slot_timeout to seconds.
Previously, idle_replication_slot_timeout was measured in minutes.
This commit changes the unit to seconds, allowing finer-grained
timeout settings.
---
doc/src/sgml/config.sgml | 2 +-
src/backend/replication/slot.c | 15 ++++++---------
src/backend/utils/misc/guc_tables.c | 6 +++---
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/include/replication/slot.h | 2 +-
5 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 59a0874528a..bd12225cbe4 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4620,7 +4620,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
<para>
Invalidate replication slots that have remained idle longer than this
duration. If this value is specified without units, it is taken as
- minutes. A value of zero (the default) disables the idle timeout
+ seconds. A value of zero (the default) disables the idle timeout
invalidation mechanism. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command
line.
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index f9fec50ae88..a6512034ba7 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -154,7 +154,7 @@ int max_replication_slots = 10; /* the maximum number of replication
* Invalidate replication slots that have remained idle longer than this
* duration; '0' disables it.
*/
-int idle_replication_slot_timeout_mins = 0;
+int idle_replication_slot_timeout_secs = 0;
/*
* This GUC lists streaming replication standby server slot names that
@@ -1612,13 +1612,10 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
case RS_INVAL_IDLE_TIMEOUT:
{
- int minutes = slot_idle_seconds / SECS_PER_MINUTE;
- int secs = slot_idle_seconds % SECS_PER_MINUTE;
-
/* translator: %s is a GUC variable name */
- appendStringInfo(&err_detail, _("The slot's idle time of %dmin %02ds exceeds the configured \"%s\" duration of %dmin."),
- minutes, secs, "idle_replication_slot_timeout",
- idle_replication_slot_timeout_mins);
+ appendStringInfo(&err_detail, _("The slot's idle time of %lds exceeds the configured \"%s\" duration of %ds."),
+ slot_idle_seconds, "idle_replication_slot_timeout",
+ idle_replication_slot_timeout_secs);
/* translator: %s is a GUC variable name */
appendStringInfo(&err_hint, _("You might need to increase \"%s\"."),
"idle_replication_slot_timeout");
@@ -1656,7 +1653,7 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
static inline bool
CanInvalidateIdleSlot(ReplicationSlot *s)
{
- return (idle_replication_slot_timeout_mins != 0 &&
+ return (idle_replication_slot_timeout_secs != 0 &&
!XLogRecPtrIsInvalid(s->data.restart_lsn) &&
s->inactive_since > 0 &&
!(RecoveryInProgress() && s->data.synced));
@@ -1734,7 +1731,7 @@ DetermineSlotInvalidationCause(uint32 possible_causes, ReplicationSlot *s,
* idle_replication_slot_timeout GUC.
*/
if (TimestampDifferenceExceedsSeconds(s->inactive_since, now,
- idle_replication_slot_timeout_mins * SECS_PER_MINUTE))
+ idle_replication_slot_timeout_secs))
{
*inactive_since = s->inactive_since;
return RS_INVAL_IDLE_TIMEOUT;
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 511dc32d519..a925be86944 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -3100,10 +3100,10 @@ struct config_int ConfigureNamesInt[] =
gettext_noop("Sets the duration a replication slot can remain idle before "
"it is invalidated."),
NULL,
- GUC_UNIT_MIN
+ GUC_UNIT_S
},
- &idle_replication_slot_timeout_mins,
- 0, 0, INT_MAX / SECS_PER_MINUTE,
+ &idle_replication_slot_timeout_secs,
+ 0, 0, INT_MAX,
check_idle_replication_slot_timeout, NULL, NULL
},
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 341f88adc87..a9d8293474a 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -342,7 +342,7 @@
# (change requires restart)
#wal_keep_size = 0 # in megabytes; 0 disables
#max_slot_wal_keep_size = -1 # in megabytes; -1 disables
-#idle_replication_slot_timeout = 0 # in minutes; 0 disables
+#idle_replication_slot_timeout = 0 # in seconds; 0 disables
#wal_sender_timeout = 60s # in milliseconds; 0 disables
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
diff --git a/src/include/replication/slot.h b/src/include/replication/slot.h
index ffacba9d2ae..76aeeb92242 100644
--- a/src/include/replication/slot.h
+++ b/src/include/replication/slot.h
@@ -266,7 +266,7 @@ extern PGDLLIMPORT ReplicationSlot *MyReplicationSlot;
/* GUCs */
extern PGDLLIMPORT int max_replication_slots;
extern PGDLLIMPORT char *synchronized_standby_slots;
-extern PGDLLIMPORT int idle_replication_slot_timeout_mins;
+extern PGDLLIMPORT int idle_replication_slot_timeout_secs;
/* shmem initialization functions */
extern Size ReplicationSlotsShmemSize(void);
--
2.49.0
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-04 16:07 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 2 replies; 38+ messages in thread
From: Laurenz Albe @ 2025-07-04 16:07 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; +Cc: pgsql-bugs@lists.postgresql.org
On Sat, 2025-07-05 at 00:22 +0900, Fujii Masao wrote:
> On 2025/07/04 23:12, Fujii Masao wrote:
> > But I wonder why the current unit of this GUC is minutes (GUC_UNIT_MIN).
> > Since at least two users (including myself) tried to set it to a value
> > less than 1 minute, it might worth considering changing the unit to seconds
> > (GUC_UNIT_S). Also which would reduces the chance of the reported trouble.
>
> Attached patch changes unit of idle_replication_slot_timeout to seconds.
-1
I think that the reason that several users tried to set it it less than a minute
is that they were trying to test the feature and didn't want to wait long.
I cannot imagine that anybody will want to abandon a standby server just
because it is idle for more than 30 seconds.
For me, there would be two appealing alternatives:
1. Always round up to the next minute.
2. Use the value -1 to deactivate the feature.
Optionally, we could forbid the value 0 in this case.
Stepping back a bit, I am not happy with the documentation. I looked at it,
trying to figure out what the parameter does, and I am none the wiser.
What exactly does it mean for a replication slot to idle?
- Does it mean that the standby is not connected?
- Does it mean that the standby is connected, but gives no feedback?
Probably not, but I only guess that because I know that there is a different
parameter for that.
- Does it mean that the standby is giving feedback, but that feedback doesn't
indicate progress?
I think we could do better here.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-04 16:24 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 3 replies; 38+ messages in thread
From: Fujii Masao @ 2025-07-04 16:24 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; +Cc: pgsql-bugs@lists.postgresql.org
On 2025/07/05 1:07, Laurenz Albe wrote:
> On Sat, 2025-07-05 at 00:22 +0900, Fujii Masao wrote:
>> On 2025/07/04 23:12, Fujii Masao wrote:
>>> But I wonder why the current unit of this GUC is minutes (GUC_UNIT_MIN).
>>> Since at least two users (including myself) tried to set it to a value
>>> less than 1 minute, it might worth considering changing the unit to seconds
>>> (GUC_UNIT_S). Also which would reduces the chance of the reported trouble.
>>
>> Attached patch changes unit of idle_replication_slot_timeout to seconds.
>
> -1
>
> I think that the reason that several users tried to set it it less than a minute
> is that they were trying to test the feature and didn't want to wait long.
> I cannot imagine that anybody will want to abandon a standby server just
> because it is idle for more than 30 seconds.
Maybe. But changing the unit to seconds doesn't make things worse, does it?
It still allows users to set values greater than 1 minute, and also less than
1 minute for debugging or testing purposes, if needed.
Or are you suggesting we should disallow values below 1 minute?
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-04 18:59 Gunnar Morling <gunnar.morling@googlemail.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
2 siblings, 0 replies; 38+ messages in thread
From: Gunnar Morling @ 2025-07-04 18:59 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; pgsql-bugs@lists.postgresql.org
Hey all,
Thanks for all the replies!
Indeed I also wouldn't expect anyone to set this timeout to 30s for
purposes other than testing or exploration. But then again, if the option
can be set with second precision, is there any reason to not honor this? To
me, it boils down to the principle of least surprise for users, in
particular when it comes to a setting like "30s" being interpreted as
disabling the feature.
> What exactly does it mean for a replication slot to idle?
I'd like to echo this; I also was/am confused by the term "idle" here; it
isn't fully clear to me what it means for a slot to be idle, and in
particular whether it is different from a slot being inactive.
pg_replication_slots uses the "active"/"inactive" terminology, and it seems
that this is what idleness is about, as per the docs of the setting [1]:
> [Users] can force a checkpoint to promptly invalidate inactive slots. The
duration of slot inactivity is calculated using the slot's
pg_replication_slots.inactive_since value.
If so, "inactive_replication_slot_timeout" might be a more consistent name
for that option?
Best,
--Gunnar
[1]
https://www.postgresql.org/docs/18/runtime-config-replication.html#GUC-IDLE-REPLICATION-SLOT-TIMEOUT
On Fri, 4 Jul 2025 at 18:24, Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:
>
>
> On 2025/07/05 1:07, Laurenz Albe wrote:
> > On Sat, 2025-07-05 at 00:22 +0900, Fujii Masao wrote:
> >> On 2025/07/04 23:12, Fujii Masao wrote:
> >>> But I wonder why the current unit of this GUC is minutes
> (GUC_UNIT_MIN).
> >>> Since at least two users (including myself) tried to set it to a value
> >>> less than 1 minute, it might worth considering changing the unit to
> seconds
> >>> (GUC_UNIT_S). Also which would reduces the chance of the reported
> trouble.
> >>
> >> Attached patch changes unit of idle_replication_slot_timeout to seconds.
> >
> > -1
> >
> > I think that the reason that several users tried to set it it less than
> a minute
> > is that they were trying to test the feature and didn't want to wait
> long.
> > I cannot imagine that anybody will want to abandon a standby server just
> > because it is idle for more than 30 seconds.
>
> Maybe. But changing the unit to seconds doesn't make things worse, does it?
> It still allows users to set values greater than 1 minute, and also less
> than
> 1 minute for debugging or testing purposes, if needed.
>
> Or are you suggesting we should disallow values below 1 minute?
>
> Regards,
>
> --
> Fujii Masao
> NTT DATA Japan Corporation
>
>
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-04 22:08 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
2 siblings, 0 replies; 38+ messages in thread
From: Laurenz Albe @ 2025-07-04 22:08 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; +Cc: pgsql-bugs@lists.postgresql.org
On Sat, 2025-07-05 at 01:24 +0900, Fujii Masao wrote:
> On 2025/07/05 1:07, Laurenz Albe wrote:
> > On Sat, 2025-07-05 at 00:22 +0900, Fujii Masao wrote:
> > > On 2025/07/04 23:12, Fujii Masao wrote:
> > > > But I wonder why the current unit of this GUC is minutes (GUC_UNIT_MIN).
> > > > Since at least two users (including myself) tried to set it to a value
> > > > less than 1 minute, it might worth considering changing the unit to seconds
> > > > (GUC_UNIT_S). Also which would reduces the chance of the reported trouble.
> > >
> > > Attached patch changes unit of idle_replication_slot_timeout to seconds.
> >
> > -1
> >
> > I think that the reason that several users tried to set it it less than a minute
> > is that they were trying to test the feature and didn't want to wait long.
> > I cannot imagine that anybody will want to abandon a standby server just
> > because it is idle for more than 30 seconds.
>
> Maybe. But changing the unit to seconds doesn't make things worse, does it?
> It still allows users to set values greater than 1 minute, and also less than
> 1 minute for debugging or testing purposes, if needed.
>
> Or are you suggesting we should disallow values below 1 minute?
I guess you are right. There is no problem with second precision, even if
the use case in this case was artificial.
I withdraw my objection.
Gunnar Morlin wrote:
> I also was/am confused by the term "idle" here; it isn't fully clear to me
> what it means for a slot to be idle, and in particular whether it is different
> from a slot being inactive. [...]
>
> If so, "inactive_replication_slot_timeout" might be a more consistent name
> for that option?
Perhaps. I must say that I don't care so much about the name, as long as the
documentation doesn't leave any doubts.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 04:06 Amit Kapila <amit.kapila16@gmail.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
2 siblings, 1 reply; 38+ messages in thread
From: Amit Kapila @ 2025-07-05 04:06 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org
On Fri, Jul 4, 2025 at 9:54 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
> On 2025/07/05 1:07, Laurenz Albe wrote:
> > On Sat, 2025-07-05 at 00:22 +0900, Fujii Masao wrote:
> >> On 2025/07/04 23:12, Fujii Masao wrote:
> >>> But I wonder why the current unit of this GUC is minutes (GUC_UNIT_MIN).
> >>> Since at least two users (including myself) tried to set it to a value
> >>> less than 1 minute, it might worth considering changing the unit to seconds
> >>> (GUC_UNIT_S). Also which would reduces the chance of the reported trouble.
> >>
> >> Attached patch changes unit of idle_replication_slot_timeout to seconds.
> >
> > -1
> >
> > I think that the reason that several users tried to set it it less than a minute
> > is that they were trying to test the feature and didn't want to wait long.
> > I cannot imagine that anybody will want to abandon a standby server just
> > because it is idle for more than 30 seconds.
>
> Maybe. But changing the unit to seconds doesn't make things worse, does it?
> It still allows users to set values greater than 1 minute, and also less than
> 1 minute for debugging or testing purposes, if needed.
>
We expect the value of this variable to be in hours or, in some cases,
days. Specifying in seconds would be inconvenient for users. Now, I
agree there is a value in testing/debugging to allow it to be seconds,
but the same could be said for other variables whose units are in
minutes, like log_rotation_age and wal_summary_keep_time.
> Or are you suggesting we should disallow values below 1 minute?
>
We should be consistent with other similar GUC variables whose unit is
in GUC_UNIT_MIN.
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 04:22 Amit Kapila <amit.kapila16@gmail.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 1 reply; 38+ messages in thread
From: Amit Kapila @ 2025-07-05 04:22 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org
On Fri, Jul 4, 2025 at 9:37 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> Stepping back a bit, I am not happy with the documentation. I looked at it,
> trying to figure out what the parameter does, and I am none the wiser.
> What exactly does it mean for a replication slot to idle?
>
> - Does it mean that the standby is not connected?
>
It means the above. The slot is used for purposes other than the
standby as well, so we can't mention something only specific to the
standby. This parameter mainly cares when the slot becomes inactive.
You can get more information by looking at
pg_replication_slots.inactive_since (as indicated by sentence: "The
duration of slot inactivity is calculated using the slot's
pg_replication_slots.inactive_since value.").
>
> I think we could do better here.
>
Sure, feel free to propose what you think makes it better.
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 05:35 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 2 replies; 38+ messages in thread
From: Laurenz Albe @ 2025-07-05 05:35 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org
On Sat, 2025-07-05 at 09:52 +0530, Amit Kapila wrote:
> On Fri, Jul 4, 2025 at 9:37 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> > What exactly does it mean for a replication slot to idle?
> >
> > - Does it mean that the standby is not connected?
>
> It means the above. The slot is used for purposes other than the
> standby as well, so we can't mention something only specific to the
> standby.
>
> > I think we could do better here.
>
> Sure, feel free to propose what you think makes it better.
Done in the attached patch.
> We expect the value of this variable to be in hours or, in some cases,
> days. Specifying in seconds would be inconvenient for users.
I don't buy that argument. Specifying shared_buffers in 8kB blocks
would be quite inconvenient to most users, but I don't remember any
complaints about it. One of the nice things about the Grand Unified
Configuration is that you can use units different from the default.
On the other hand, if the behavior is clearly documented, as I have
tried to do with my patch, it should be fine. So I'll rest my case if
you apply my patch.
Yours,
Laurenz Albe
Attachments:
[text/x-patch] v1-0001-Improve-doc-for-idle_replication_slot_timeout.patch (1.9K, ../../3422d282fd45e460b4ce1bd0745523ba63bd3848.camel@cybertec.at/2-v1-0001-Improve-doc-for-idle_replication_slot_timeout.patch)
download | inline diff:
From e49ad0034ee55577c8e881b9ba4232031ba639e2 Mon Sep 17 00:00:00 2001
From: Laurenz Albe <laurenz.albe@cybertec.at>
Date: Sat, 5 Jul 2025 07:27:10 +0200
Subject: [PATCH v1] Improve doc for idle_replication_slot_timeout
Define what exactly is meant by "idle" here. Also, emphasize that
the value is rounded to minutes, since that caused some surprise
during beta testing.
Author: Laurenz Albe <laurenz.albe@cybertec.at>
Discussion: https://postgr.es/m/CADGJaX_0%2BFTguWpNSpgVWYQP_7MhoO0D8%3Dcp4XozSQgaZ40Odw%40mail.gmail.com
---
doc/src/sgml/config.sgml | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 59a0874528a..2b4f9f34cf4 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4618,12 +4618,14 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</term>
<listitem>
<para>
- Invalidate replication slots that have remained idle longer than this
- duration. If this value is specified without units, it is taken as
- minutes. A value of zero (the default) disables the idle timeout
- invalidation mechanism. This parameter can only be set in the
- <filename>postgresql.conf</filename> file or on the server command
- line.
+ Invalidate replication slots that have been inactive (not used by a
+ <link linkend="protocol-replication">replication connection</link>)
+ for longer than this duration. If the value is specified without
+ units, it is taken as minutes. Values specified in units smaller than
+ a minute are rounded to the nearest minute. A value of zero (the
+ default) disables the idle timeout invalidation mechanism. This
+ parameter can only be set in the <filename>postgresql.conf</filename>
+ file or on the server command line.
</para>
<para>
--
2.50.0
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 05:55 David G. Johnston <david.g.johnston@gmail.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 0 replies; 38+ messages in thread
From: David G. Johnston @ 2025-07-05 05:55 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Friday, July 4, 2025, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> One of the nice things about the Grand Unified
> Configuration is that you can use units different from the default.
>
Supplying the value as '2 h', SHOW will display 2h while
pg_settings.setting shows 120 (min).
David J.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 06:16 David G. Johnston <david.g.johnston@gmail.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 2 replies; 38+ messages in thread
From: David G. Johnston @ 2025-07-05 06:16 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org
On Fri, Jul 4, 2025 at 10:35 PM Laurenz Albe <laurenz.albe@cybertec.at>
wrote:
> On the other hand, if the behavior is clearly documented, as I have
> tried to do with my patch, it should be fine. So I'll rest my case if
> you apply my patch.
>
>
We should clearly document how rounding works in section 19.1.1 (which we
mostly do; "If the parameter is of integer type, a final rounding to
integer occurs after any unit conversion.") and not in every time-related
setting that chooses to use something larger than microseconds. So, 30s is
'unit converted' up to 0.5 minutes (not explicitly explained...) then
rounded to zero (which is odd, half normally rounds up...). I'm against
cluttering up the individual settings docs with this detail.
If the change from idle to inactive is needed in the description we
should just admit we named it wrong in the first place. As-is, the
description matches the name and the callout to the field in the second
paragraph precisely clears up what this setting at least cares about. The
reader should be directed to how that field is computed should they need
clarification.
Thus, I'd accept but not find required the idle/inactive wording change to
any of various degrees; and would ask that any clarification regarding
generic setting value interpretation be relegated to 19.1.1 where all such
settings can benefit.
David J.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 08:47 Laurenz Albe <laurenz.albe@cybertec.at>
parent: David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 1 reply; 38+ messages in thread
From: Laurenz Albe @ 2025-07-05 08:47 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: smithpb2250@gmail.com, Amit Kapila <amit.kapila16@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org
On Fri, 2025-07-04 at 23:16 -0700, David G. Johnston wrote:
> We should clearly document how rounding works in section 19.1.1
> (which we mostly do; "If the parameter is of integer type, a final rounding
> to integer occurs after any unit conversion.") and not in every
> time-related setting that chooses to use something larger than microseconds.
> So, 30s is 'unit converted' up to 0.5 minutes (not explicitly explained...)
> then rounded to zero (which is odd, half normally rounds up...).
> I'm against cluttering up the individual settings docs with this detail.
That's fine with me; do you have a patch?
> If the change from idle to inactive is needed in the description we should
> just admit we named it wrong in the first place.
I had half a mind to propose renaming the parameter, but I shied from
a lengthy bikeshedding discussion. Reading up on the archives, I see
that Peter Smith proposed the term "idle" in [1], and nobody had any
problem with it.
For the record: I would be much more happy if the parameter were called
"inactive_replication_slot_timeout", since we use the term "active" in
"pg_replication_slots". Also, we call connections "idle" when they are
established, but doing nothing, and this parameter is about disconnected
replication connections.
> As-is, the description
> matches the name and the callout to the field in the second paragraph
> precisely clears up what this setting at least cares about. The reader
> should be directed to how that field is computed should they need clarification.
>
> Thus, I'd accept but not find required the idle/inactive wording change to
> any of various degrees; and would ask that any clarification regarding
> generic setting value interpretation be relegated to 19.1.1 where all
> such settings can benefit.
I am sure that there is some information in these sentences, but I cannot
extract it, even after reading them twice.
Yours,
Laurenz Albe
[1]: https://postgr.es/m/CAHut%2BPtHbYNxPvtMfs7jARbsVcFXL1%3DC9SO3Q93NgVDgbKN7LQ%40mail.gmail.com
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 14:38 David G. Johnston <david.g.johnston@gmail.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 0 replies; 38+ messages in thread
From: David G. Johnston @ 2025-07-05 14:38 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: smithpb2250@gmail.com <smithpb2250@gmail.com>; Amit Kapila <amit.kapila16@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Saturday, July 5, 2025, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
>
> I am sure that there is some information in these sentences, but I cannot
> extract it, even after reading them twice.
>
>
Maybe: “During checkpoint if the interval since
pg_replication_slots.inactive_since and now is larger than this value
pg_replication_slots.conflicting is set to true and
pg_replication_slots.inactive_reason is set to ‘timeout’. See section
wherever for more information on handling conflicted slots.”
Heck, writing this, “idle” is probably better, a slot can recover from
being idle on its own but usually inactive would imply having to do
something to make it active again.
IMO our documentation for replication has serious flaws but this particular
area is clear enough. Like any good timeout the slot is killed if it goes
unused “idle” for some length of time. We can describe that in many ways
but the name, to me, is fully descriptive and consistent with other
timeouts like “idle_in_transaction_timeout”.
David J.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 14:44 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Fujii Masao @ 2025-07-05 14:44 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org
On 2025/07/05 13:06, Amit Kapila wrote:
> On Fri, Jul 4, 2025 at 9:54 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>
>> On 2025/07/05 1:07, Laurenz Albe wrote:
>>> On Sat, 2025-07-05 at 00:22 +0900, Fujii Masao wrote:
>>>> On 2025/07/04 23:12, Fujii Masao wrote:
>>>>> But I wonder why the current unit of this GUC is minutes (GUC_UNIT_MIN).
>>>>> Since at least two users (including myself) tried to set it to a value
>>>>> less than 1 minute, it might worth considering changing the unit to seconds
>>>>> (GUC_UNIT_S). Also which would reduces the chance of the reported trouble.
>>>>
>>>> Attached patch changes unit of idle_replication_slot_timeout to seconds.
>>>
>>> -1
>>>
>>> I think that the reason that several users tried to set it it less than a minute
>>> is that they were trying to test the feature and didn't want to wait long.
>>> I cannot imagine that anybody will want to abandon a standby server just
>>> because it is idle for more than 30 seconds.
>>
>> Maybe. But changing the unit to seconds doesn't make things worse, does it?
>> It still allows users to set values greater than 1 minute, and also less than
>> 1 minute for debugging or testing purposes, if needed.
>>
>
> We expect the value of this variable to be in hours or, in some cases,
> days. Specifying in seconds would be inconvenient for users. Now, I
> agree there is a value in testing/debugging to allow it to be seconds,
> but the same could be said for other variables whose units are in
> minutes, like log_rotation_age and wal_summary_keep_time.
Even if we change the unit to seconds (GUC_UNIT_S), it's still possible
to set the timeout values such as hours or days. For example, even with
the patch, we can set the timeout to 365 days:
=# ALTER SYSTEM SET idle_replication_slot_timeout TO '365d';
=# SELECT pg_reload_conf();
=# SHOW idle_replication_slot_timeout ;
idle_replication_slot_timeout
-------------------------------
365d
(1 row)
Do you see any serious downside to switching the unit to seconds? I don't
think it introduces any serious issues. On the contrary, it gives users finer
control over the timeout, and additionally works around the issue
that we're discussing here.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 15:07 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 1 reply; 38+ messages in thread
From: Fujii Masao @ 2025-07-05 15:07 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org
On 2025/07/05 15:16, David G. Johnston wrote:
> On Fri, Jul 4, 2025 at 10:35 PM Laurenz Albe <laurenz.albe@cybertec.at <mailto:laurenz.albe@cybertec.at>> wrote:
>
> On the other hand, if the behavior is clearly documented, as I have
> tried to do with my patch, it should be fine. So I'll rest my case if
> you apply my patch.
>
>
> We should clearly document how rounding works in section 19.1.1 (which we mostly do; "If the parameter is of integer type, a final rounding to integer occurs after any unit conversion.") and not in every time-related setting that chooses to use something larger than microseconds. So, 30s is 'unit converted' up to 0.5 minutes (not explicitly explained...) then rounded to zero (which is odd, half normally rounds up...).
This happens because in this case rounding is done using rint(3),
which uses banker's rounding by default. While the rint(3)'s rounding method
can be changed with fesetround(), PostgreSQL doesn't seem to change it.
So 0.5 rounds to 0, 1.5 and 2.5 round to 2, 3.5 and 4.5 round to 4, and so on.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 15:10 David G. Johnston <david.g.johnston@gmail.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 38+ messages in thread
From: David G. Johnston @ 2025-07-05 15:10 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Saturday, July 5, 2025, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
> Do you see any serious downside to switching the unit to seconds? I don't
> think it introduces any serious issues. On the contrary, it gives users
> finer
> control over the timeout, and additionally works around the issue
> that we're discussing here.
>
I do not, and would rather we make the change. Minutes are an
unconventional base unit for time in our world and should be avoided.
David J.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 15:12 David G. Johnston <david.g.johnston@gmail.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 0 replies; 38+ messages in thread
From: David G. Johnston @ 2025-07-05 15:12 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Amit Kapila <amit.kapila16@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Saturday, July 5, 2025, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
> On 2025/07/05 15:16, David G. Johnston wrote:
>
>> On Fri, Jul 4, 2025 at 10:35 PM Laurenz Albe <laurenz.albe@cybertec.at
>> <mailto:laurenz.albe@cybertec.at>> wrote:
>>
>> On the other hand, if the behavior is clearly documented, as I have
>> tried to do with my patch, it should be fine. So I'll rest my case if
>> you apply my patch.
>>
>>
>> We should clearly document how rounding works in section 19.1.1 (which we
>> mostly do; "If the parameter is of integer type, a final rounding to
>> integer occurs after any unit conversion.") and not in every time-related
>> setting that chooses to use something larger than microseconds. So, 30s is
>> 'unit converted' up to 0.5 minutes (not explicitly explained...) then
>> rounded to zero (which is odd, half normally rounds up...).
>>
>
> This happens because in this case rounding is done using rint(3),
> which uses banker's rounding by default. While the rint(3)'s rounding
> method
> can be changed with fesetround(), PostgreSQL doesn't seem to change it.
> So 0.5 rounds to 0, 1.5 and 2.5 round to 2, 3.5 and 4.5 round to 4, and so
> on.
>
Right, a.k.a., half-even rounding. So, not odd.
David J.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 15:56 Tom Lane <tgl@sss.pgh.pa.us>
parent: David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Tom Lane @ 2025-07-05 15:56 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Fujii Masao <masao.fujii@oss.nttdata.com>; Amit Kapila <amit.kapila16@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Saturday, July 5, 2025, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>> Do you see any serious downside to switching the unit to seconds? I don't
>> think it introduces any serious issues. On the contrary, it gives users
>> finer
>> control over the timeout, and additionally works around the issue
>> that we're discussing here.
> I do not, and would rather we make the change. Minutes are an
> unconventional base unit for time in our world and should be avoided.
By my count, there are ten GUCs declared with GUC_UNIT_S and three
with GUC_UNIT_MIN. I'd say that there may be some lean towards
seconds but David's argument seems like pure hyperbole.
I'm kind of down on changing the unit, because it will *silently*
break configuration files where the value was set without a unit.
May I suggest an alternative? We could change the variable from int
to float type and continue to specify it in minutes. That will have
exactly zero compatibility impact, it allows sub-minute values to
be selected at need, and it removes the need for hair-splitting
documentation about what the rounding rules are.
We previously did the same with vacuum_cost_delay to avoid worries
about how to specify sub-millisecond precision for that. So the
infrastructure is already in place, I think. The patch will be
different from what is proposed but should need to touch pretty
much the same places.
regards, tom lane
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-05 16:13 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 3 replies; 38+ messages in thread
From: Tom Lane @ 2025-07-05 16:13 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Fujii Masao <masao.fujii@oss.nttdata.com>; Amit Kapila <amit.kapila16@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
I wrote:
> I'm kind of down on changing the unit, because it will *silently*
> break configuration files where the value was set without a unit.
Oh, wait a second. I just noticed that this variable is new in v18.
So there won't be a compatibility issue as long as we change it in
v18 too. So changing it to a base of seconds seems sufficient,
and more in line with existing practice:
regression=# select name,unit from pg_settings where name like '%timeout';
name | unit
-------------------------------------+------
archive_timeout | s
authentication_timeout | s
checkpoint_timeout | s
deadlock_timeout | ms
idle_in_transaction_session_timeout | ms
idle_replication_slot_timeout | min
idle_session_timeout | ms
lock_timeout | ms
statement_timeout | ms
tcp_user_timeout | ms
transaction_timeout | ms
wal_receiver_timeout | ms
wal_sender_timeout | ms
(13 rows)
Using 'ms' seems clearly overkill, but there's precedent for
timeouts measured in seconds.
regards, tom lane
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-08 16:42 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 38+ messages in thread
From: Fujii Masao @ 2025-07-08 16:42 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; +Cc: Amit Kapila <amit.kapila16@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 2025/07/06 1:13, Tom Lane wrote:
> I wrote:
>> I'm kind of down on changing the unit, because it will *silently*
>> break configuration files where the value was set without a unit.
>
> Oh, wait a second. I just noticed that this variable is new in v18.
> So there won't be a compatibility issue as long as we change it in
> v18 too. So changing it to a base of seconds seems sufficient,
> and more in line with existing practice:
Yes!
It seems there are currently no clear objections to the patch that
changes the unit of idle_replication_slot_timeout to seconds.
If that's the case, I'm planning to commit it to both master and v18.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-08 16:53 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 38+ messages in thread
From: Laurenz Albe @ 2025-07-08 16:53 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; +Cc: Fujii Masao <masao.fujii@oss.nttdata.com>; Amit Kapila <amit.kapila16@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Sat, 2025-07-05 at 12:13 -0400, Tom Lane wrote:
> Oh, wait a second. I just noticed that this variable is new in v18.
> So there won't be a compatibility issue as long as we change it in
> v18 too. So changing it to a base of seconds seems sufficient,
> and more in line with existing practice:
>
> Using 'ms' seems clearly overkill, but there's precedent for
> timeouts measured in seconds.
Here is a patch that changes the unit to seconds, like Fujii Masao's
patch upthread. In addition, it removes the now unnecessary injection
point for the TAP test and tries to improve the documentation to
address my complaints.
Yours,
Laurenz Albe
Attachments:
[text/x-patch] v2-0001-Change-idle_replication_slot_timeout-unit-to-seco.patch (10.3K, ../../f12271e6aea3b87eaa430d0c9008ca1f3154c31e.camel@cybertec.at/2-v2-0001-Change-idle_replication_slot_timeout-unit-to-seco.patch)
download | inline diff:
From acc88781735355d41e905a2d551a38dc8478ea53 Mon Sep 17 00:00:00 2001
From: Laurenz Albe <laurenz.albe@cybertec.at>
Date: Tue, 8 Jul 2025 18:47:56 +0200
Subject: [PATCH v2] Change idle_replication_slot_timeout unit to seconds
While there is nothing fundamentally wrong with the original unit
of minutes, having a precision of seconds has some advantages:
First, it makes testing easier. We don't need an injection point to
test the parameter in a TAP test, since we can afford to wait for two
seconds for replication slots to become invalid. Also, the original
complaint that led to this patch was that the timeout was rounded to
minutes (as it should be), so values below 30 seconds resulted in an
effective setting of 0, which disabled the timeout to surprise of the
testers.
While at it, improve the documentation to clarify that "idle" in this
context is the same as "inactive" (no replication connection is
currently using the slot). Otherwise, "idle" might be misunderstood
as "the replication slot is not advanced" or "nothing is streamed on
the replication connection".
Reported-by: Gunnar Morling <gunnar.morling@googlemail.com>
Author: Fujii Masao <masao.fujii@oss.nttdata.com>
Author: Laurenz Albe <laurenz.albe@cybertec.at>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CADGJaX_0%2BFTguWpNSpgVWYQP_7MhoO0D8%3Dcp4XozSQgaZ40Odw%40mail.gmail.com
---
doc/src/sgml/config.sgml | 7 +++--
doc/src/sgml/system-views.sgml | 2 +-
src/backend/replication/slot.c | 30 +++++--------------
src/backend/utils/misc/guc_tables.c | 6 ++--
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/include/replication/slot.h | 2 +-
.../t/044_invalidate_inactive_slots.pl | 27 ++---------------
7 files changed, 20 insertions(+), 56 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 59a0874528a..09d33069385 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4618,9 +4618,10 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</term>
<listitem>
<para>
- Invalidate replication slots that have remained idle longer than this
- duration. If this value is specified without units, it is taken as
- minutes. A value of zero (the default) disables the idle timeout
+ Invalidate replication slots that have remained inactive (not used by a
+ <link linkend="protocol-replication">replication connection</link>) for
+ longer than this duration. If this value is specified without units, it
+ is taken as seconds. A value of zero (the default) disables the idle timeout
invalidation mechanism. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command
line.
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 986ae1f543d..89f20d4ce6e 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2932,7 +2932,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
<listitem>
<para>
<literal>idle_timeout</literal> means that the slot has remained
- idle longer than the configured
+ inactive longer than the configured
<xref linkend="guc-idle-replication-slot-timeout"/> duration.
</para>
</listitem>
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index f9fec50ae88..cc13cbb2d9a 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -154,7 +154,7 @@ int max_replication_slots = 10; /* the maximum number of replication
* Invalidate replication slots that have remained idle longer than this
* duration; '0' disables it.
*/
-int idle_replication_slot_timeout_mins = 0;
+int idle_replication_slot_timeout_secs = 0;
/*
* This GUC lists streaming replication standby server slot names that
@@ -1612,13 +1612,10 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
case RS_INVAL_IDLE_TIMEOUT:
{
- int minutes = slot_idle_seconds / SECS_PER_MINUTE;
- int secs = slot_idle_seconds % SECS_PER_MINUTE;
-
/* translator: %s is a GUC variable name */
- appendStringInfo(&err_detail, _("The slot's idle time of %dmin %02ds exceeds the configured \"%s\" duration of %dmin."),
- minutes, secs, "idle_replication_slot_timeout",
- idle_replication_slot_timeout_mins);
+ appendStringInfo(&err_detail, _("The slot's idle time of %lds exceeds the configured \"%s\" duration of %ds."),
+ slot_idle_seconds, "idle_replication_slot_timeout",
+ idle_replication_slot_timeout_secs);
/* translator: %s is a GUC variable name */
appendStringInfo(&err_hint, _("You might need to increase \"%s\"."),
"idle_replication_slot_timeout");
@@ -1656,7 +1653,7 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
static inline bool
CanInvalidateIdleSlot(ReplicationSlot *s)
{
- return (idle_replication_slot_timeout_mins != 0 &&
+ return (idle_replication_slot_timeout_secs != 0 &&
!XLogRecPtrIsInvalid(s->data.restart_lsn) &&
s->inactive_since > 0 &&
!(RecoveryInProgress() && s->data.synced));
@@ -1716,25 +1713,12 @@ DetermineSlotInvalidationCause(uint32 possible_causes, ReplicationSlot *s,
if (CanInvalidateIdleSlot(s))
{
- /*
- * We simulate the invalidation due to idle_timeout as the minimum
- * time idle time is one minute which makes tests take a long
- * time.
- */
-#ifdef USE_INJECTION_POINTS
- if (IS_INJECTION_POINT_ATTACHED("slot-timeout-inval"))
- {
- *inactive_since = 0; /* since the beginning of time */
- return RS_INVAL_IDLE_TIMEOUT;
- }
-#endif
-
/*
* Check if the slot needs to be invalidated due to
* idle_replication_slot_timeout GUC.
*/
if (TimestampDifferenceExceedsSeconds(s->inactive_since, now,
- idle_replication_slot_timeout_mins * SECS_PER_MINUTE))
+ idle_replication_slot_timeout_secs))
{
*inactive_since = s->inactive_since;
return RS_INVAL_IDLE_TIMEOUT;
@@ -1895,7 +1879,7 @@ InvalidatePossiblyObsoleteSlot(uint32 possible_causes,
* max_slot_wal_keep_size is set to -1 and
* idle_replication_slot_timeout is set to 0 during the binary
* upgrade. See check_old_cluster_for_valid_slots() where we ensure
- * that no invalidated before the upgrade.
+ * that no slot was invalidated before the upgrade.
*/
Assert(!(*invalidated && SlotIsLogical(s) && IsBinaryUpgrade));
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 511dc32d519..a925be86944 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -3100,10 +3100,10 @@ struct config_int ConfigureNamesInt[] =
gettext_noop("Sets the duration a replication slot can remain idle before "
"it is invalidated."),
NULL,
- GUC_UNIT_MIN
+ GUC_UNIT_S
},
- &idle_replication_slot_timeout_mins,
- 0, 0, INT_MAX / SECS_PER_MINUTE,
+ &idle_replication_slot_timeout_secs,
+ 0, 0, INT_MAX,
check_idle_replication_slot_timeout, NULL, NULL
},
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 341f88adc87..a9d8293474a 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -342,7 +342,7 @@
# (change requires restart)
#wal_keep_size = 0 # in megabytes; 0 disables
#max_slot_wal_keep_size = -1 # in megabytes; -1 disables
-#idle_replication_slot_timeout = 0 # in minutes; 0 disables
+#idle_replication_slot_timeout = 0 # in seconds; 0 disables
#wal_sender_timeout = 60s # in milliseconds; 0 disables
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
diff --git a/src/include/replication/slot.h b/src/include/replication/slot.h
index ffacba9d2ae..76aeeb92242 100644
--- a/src/include/replication/slot.h
+++ b/src/include/replication/slot.h
@@ -266,7 +266,7 @@ extern PGDLLIMPORT ReplicationSlot *MyReplicationSlot;
/* GUCs */
extern PGDLLIMPORT int max_replication_slots;
extern PGDLLIMPORT char *synchronized_standby_slots;
-extern PGDLLIMPORT int idle_replication_slot_timeout_mins;
+extern PGDLLIMPORT int idle_replication_slot_timeout_secs;
/* shmem initialization functions */
extern Size ReplicationSlotsShmemSize(void);
diff --git a/src/test/recovery/t/044_invalidate_inactive_slots.pl b/src/test/recovery/t/044_invalidate_inactive_slots.pl
index ccace14b4dd..4abcc960f19 100644
--- a/src/test/recovery/t/044_invalidate_inactive_slots.pl
+++ b/src/test/recovery/t/044_invalidate_inactive_slots.pl
@@ -8,14 +8,6 @@ use PostgreSQL::Test::Utils;
use PostgreSQL::Test::Cluster;
use Test::More;
-# This test depends on injection point that forces slot invalidation
-# due to idle_timeout.
-# https://www.postgresql.org/docs/current/xfunc-c.html#XFUNC-ADDIN-INJECTION-POINTS
-if ($ENV{enable_injection_points} ne 'yes')
-{
- plan skip_all => 'Injection points not supported by this build';
-}
-
# Wait for slot to first become idle and then get invalidated
sub wait_for_slot_invalidation
{
@@ -51,18 +43,10 @@ $node->init(allows_streaming => 'logical');
$node->append_conf(
'postgresql.conf', qq{
checkpoint_timeout = 1h
-idle_replication_slot_timeout = 1min
+idle_replication_slot_timeout = 1s
});
$node->start;
-# Check if the 'injection_points' extension is available, as it may be
-# possible that this script is run with installcheck, where the module
-# would not be installed by default.
-if (!$node->check_extension('injection_points'))
-{
- plan skip_all => 'Extension injection_points not installed';
-}
-
# Create both physical and logical replication slots
$node->safe_psql(
'postgres', qq[
@@ -72,13 +56,8 @@ $node->safe_psql(
my $log_offset = -s $node->logfile;
-# Register an injection point on the node to forcibly cause a slot
-# invalidation due to idle_timeout
-$node->safe_psql('postgres', 'CREATE EXTENSION injection_points;');
-
-$node->safe_psql('postgres',
- "SELECT injection_points_attach('slot-timeout-inval', 'error');");
-
+# Wait a bit for the replication slots to become invalid
+$node->safe_psql('postgres', "SELECT pg_sleep(2)");
# Slot invalidation occurs during a checkpoint, so perform a checkpoint to
# invalidate the slots.
$node->safe_psql('postgres', "CHECKPOINT");
--
2.50.0
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-09 06:00 Amit Kapila <amit.kapila16@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 38+ messages in thread
From: Amit Kapila @ 2025-07-09 06:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Laurenz Albe <laurenz.albe@cybertec.at>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Sat, Jul 5, 2025 at 9:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > I'm kind of down on changing the unit, because it will *silently*
> > break configuration files where the value was set without a unit.
>
> Oh, wait a second. I just noticed that this variable is new in v18.
> So there won't be a compatibility issue as long as we change it in
> v18 too. So changing it to a base of seconds seems sufficient,
> and more in line with existing practice:
>
> regression=# select name,unit from pg_settings where name like '%timeout';
> name | unit
> -------------------------------------+------
> archive_timeout | s
> authentication_timeout | s
> checkpoint_timeout | s
> deadlock_timeout | ms
> idle_in_transaction_session_timeout | ms
> idle_replication_slot_timeout | min
> idle_session_timeout | ms
> lock_timeout | ms
> statement_timeout | ms
> tcp_user_timeout | ms
> transaction_timeout | ms
> wal_receiver_timeout | ms
> wal_sender_timeout | ms
> (13 rows)
>
> Using 'ms' seems clearly overkill, but there's precedent for
> timeouts measured in seconds.
>
Agreed, but it is unclear to me in how many of these cases users would
always need to give values in hours or more. In case of
idle_replication_slot_timeout, there is less chance that many people
would like to use the value in seconds in production. Say, tomorrow,
we want to assign some default value to this GUC, it is likely that we
would choose some value in minutes. Based on this thinking, we decided
to keep the unit of this GUC as minutes. But I see the theory of
consistency with a larger number of similar-sounding GUCs and the
developer testing theory to keep this value in seconds. So, if more
people prefer to use the unit as seconds and are not convinced by the
points I made, we should go ahead and change it.
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-09 06:35 Amit Kapila <amit.kapila16@gmail.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 38+ messages in thread
From: Amit Kapila @ 2025-07-09 06:35 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Tue, Jul 8, 2025 at 10:23 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Sat, 2025-07-05 at 12:13 -0400, Tom Lane wrote:
> > Oh, wait a second. I just noticed that this variable is new in v18.
> > So there won't be a compatibility issue as long as we change it in
> > v18 too. So changing it to a base of seconds seems sufficient,
> > and more in line with existing practice:
> >
> > Using 'ms' seems clearly overkill, but there's precedent for
> > timeouts measured in seconds.
>
> Here is a patch that changes the unit to seconds, like Fujii Masao's
> patch upthread. In addition, it removes the now unnecessary injection
> point for the TAP test and tries to improve the documentation to
> address my complaints.
>
+# Wait a bit for the replication slots to become invalid
+$node->safe_psql('postgres', "SELECT pg_sleep(2)");
Is it a good idea to add 2s to 'make check-world' for one particular test?
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-09 07:12 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Laurenz Albe @ 2025-07-09 07:12 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Wed, 2025-07-09 at 12:05 +0530, Amit Kapila wrote:
> On Tue, Jul 8, 2025 at 10:23 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> >
> > On Sat, 2025-07-05 at 12:13 -0400, Tom Lane wrote:
> > > Oh, wait a second. I just noticed that this variable is new in v18.
> > > So there won't be a compatibility issue as long as we change it in
> > > v18 too. So changing it to a base of seconds seems sufficient,
> > > and more in line with existing practice:
> > >
> > > Using 'ms' seems clearly overkill, but there's precedent for
> > > timeouts measured in seconds.
> >
> > Here is a patch that changes the unit to seconds, like Fujii Masao's
> > patch upthread. In addition, it removes the now unnecessary injection
> > point for the TAP test and tries to improve the documentation to
> > address my complaints.
> >
>
> +# Wait a bit for the replication slots to become invalid
> +$node->safe_psql('postgres', "SELECT pg_sleep(2)");
>
> Is it a good idea to add 2s to 'make check-world' for one particular test?
That is debatable. I thought that adding two seconds would be worth the
advantage of removing the injection point that only fakes the timeout.
We'd get better test coverage.
But if the people who run the regression tests dozens of times every day
object to the two seconds, I won't insist on this part of the patch.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 38+ messages in thread
* RE: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-09 07:24 Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 38+ messages in thread
From: Hayato Kuroda (Fujitsu) @ 2025-07-09 07:24 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Dear Laurenz, Amit,
> > +# Wait a bit for the replication slots to become invalid
> > +$node->safe_psql('postgres', "SELECT pg_sleep(2)");
> >
> > Is it a good idea to add 2s to 'make check-world' for one particular test?
>
> That is debatable. I thought that adding two seconds would be worth the
> advantage of removing the injection point that only fakes the timeout.
> We'd get better test coverage.
>
> But if the people who run the regression tests dozens of times every day
> object to the two seconds, I won't insist on this part of the patch.
I can understand both concerns. One benefit not to use the injection point is
that any machines can run the test. Currently some BF machines do not enable
the injection point, thus the feature has not been verified on these env.
However, unconditional sleep makes the test longer.
Based on that, I want to propose the hybrid approach; use injection_point_attach()
if possible, otherwise wait few seconds. One concern is that the test code may be
bit complex, but below codes was enough on my environment.
```
# Check if the 'injection_points' extension is available, as it may be
# possible that this script is run with installcheck, where the module
# would not be installed by default.
if ($node->check_extension('injection_points'))
{
# Register an injection point on the node to forcibly cause a slot
# invalidation due to idle_timeout
$node->safe_psql('postgres', 'CREATE EXTENSION injection_points;');
$node->safe_psql('postgres',
"SELECT injection_points_attach('slot-timeout-inval', 'error');");
}
else
{
# Otherwise wait a bit for the replication slots to become invalid
$node->safe_psql('postgres', "SELECT pg_sleep(2)");
}
```
Attached patch implements the idea, which can be applied atop v2. How do you think?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Attachments:
[application/octet-stream] hybrid.diffs (2.0K, ../../OSCPR01MB14966D811DB105E49289B8298F549A@OSCPR01MB14966.jpnprd01.prod.outlook.com/2-hybrid.diffs)
download
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-09 09:21 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
0 siblings, 1 reply; 38+ messages in thread
From: Laurenz Albe @ 2025-07-09 09:21 UTC (permalink / raw)
To: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Fujii Masao <masao.fujii@oss.nttdata.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Wed, 2025-07-09 at 07:24 +0000, Hayato Kuroda (Fujitsu) wrote:
> > > +# Wait a bit for the replication slots to become invalid
> > > +$node->safe_psql('postgres', "SELECT pg_sleep(2)");
> > >
> > > Is it a good idea to add 2s to 'make check-world' for one particular test?
> >
> > That is debatable. I thought that adding two seconds would be worth the
> > advantage of removing the injection point that only fakes the timeout.
> > We'd get better test coverage.
> >
> > But if the people who run the regression tests dozens of times every day
> > object to the two seconds, I won't insist on this part of the patch.
>
> I can understand both concerns. One benefit not to use the injection point is
> that any machines can run the test. Currently some BF machines do not enable
> the injection point, thus the feature has not been verified on these env.
> However, unconditional sleep makes the test longer.
>
> Based on that, I want to propose the hybrid approach; use injection_point_attach()
> if possible, otherwise wait few seconds. One concern is that the test code may be
> bit complex, but below codes was enough on my environment.
>
> ```
> # Check if the 'injection_points' extension is available, as it may be
> # possible that this script is run with installcheck, where the module
> # would not be installed by default.
> if ($node->check_extension('injection_points'))
> {
> # Register an injection point on the node to forcibly cause a slot
> # invalidation due to idle_timeout
> $node->safe_psql('postgres', 'CREATE EXTENSION injection_points;');
>
> $node->safe_psql('postgres',
> "SELECT injection_points_attach('slot-timeout-inval', 'error');");
> }
> else
> {
> # Otherwise wait a bit for the replication slots to become invalid
> $node->safe_psql('postgres', "SELECT pg_sleep(2)");
> }
> ```
>
> Attached patch implements the idea, which can be applied atop v2. How do you think?
I have no objections.
I'll leave the decision to Fujii Masao or whoever wants to commit something
in this area.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-09 10:19 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 38+ messages in thread
From: Fujii Masao @ 2025-07-09 10:19 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 2025/07/09 18:21, Laurenz Albe wrote:
> On Wed, 2025-07-09 at 07:24 +0000, Hayato Kuroda (Fujitsu) wrote:
>>>> +# Wait a bit for the replication slots to become invalid
>>>> +$node->safe_psql('postgres', "SELECT pg_sleep(2)");
>>>>
>>>> Is it a good idea to add 2s to 'make check-world' for one particular test?
>>>
>>> That is debatable. I thought that adding two seconds would be worth the
>>> advantage of removing the injection point that only fakes the timeout.
>>> We'd get better test coverage.
>>>
>>> But if the people who run the regression tests dozens of times every day
>>> object to the two seconds, I won't insist on this part of the patch.
>>
>> I can understand both concerns. One benefit not to use the injection point is
>> that any machines can run the test. Currently some BF machines do not enable
>> the injection point, thus the feature has not been verified on these env.
>> However, unconditional sleep makes the test longer.
>>
>> Based on that, I want to propose the hybrid approach; use injection_point_attach()
>> if possible, otherwise wait few seconds. One concern is that the test code may be
>> bit complex, but below codes was enough on my environment.
>>
>> ```
>> # Check if the 'injection_points' extension is available, as it may be
>> # possible that this script is run with installcheck, where the module
>> # would not be installed by default.
>> if ($node->check_extension('injection_points'))
>> {
>> # Register an injection point on the node to forcibly cause a slot
>> # invalidation due to idle_timeout
>> $node->safe_psql('postgres', 'CREATE EXTENSION injection_points;');
>>
>> $node->safe_psql('postgres',
>> "SELECT injection_points_attach('slot-timeout-inval', 'error');");
>> }
>> else
>> {
>> # Otherwise wait a bit for the replication slots to become invalid
>> $node->safe_psql('postgres', "SELECT pg_sleep(2)");
>> }
>> ```
>>
>> Attached patch implements the idea, which can be applied atop v2. How do you think?
>
> I have no objections.
So the purpose of this "hybrid approach" is to test idle_replication_slot_timeout
even in environments where the injection point isn't available? Do we really need
this additional test? It seems to me that the test using the injection point is
sufficient.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-09 15:17 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 38+ messages in thread
From: Laurenz Albe @ 2025-07-09 15:17 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Wed, 2025-07-09 at 19:19 +0900, Fujii Masao wrote:
> On 2025/07/09 18:21, Laurenz Albe wrote:
> > On Wed, 2025-07-09 at 07:24 +0000, Hayato Kuroda (Fujitsu) wrote:
> > > >
> > > Based on that, I want to propose the hybrid approach; use injection_point_attach()
> > > if possible, otherwise wait few seconds. One concern is that the test code may be
> > > bit complex, but below codes was enough on my environment.
> > >
> > > Attached patch implements the idea, which can be applied atop v2. How do you think?
> >
> > I have no objections.
>
> So the purpose of this "hybrid approach" is to test idle_replication_slot_timeout
> even in environments where the injection point isn't available? Do we really need
> this additional test? It seems to me that the test using the injection point is
> sufficient.
If you think that using the injection point is sufficient, go for it.
That means slightly less test coverage; the injection point skips the call to
TimestampDifferenceExceedsSeconds() to determine if the slot's "inactive_since"
is old enough and just unconditionally returns RS_INVAL_IDLE_TIMEOUT.
But yes, that is not a big loss.
My patch has the advantage of
a) simplifying the code,
b) running the test even if injection points are not available and
c) testing more of the code
at the price of two extra seconds for the TAP tests.
The "hybrid approach" saves the two seconds on system with injection points,
but cannot simplify the code.
I personally can live with all three; my personal preference is my patch.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-10 03:27 Amit Kapila <amit.kapila16@gmail.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 38+ messages in thread
From: Amit Kapila @ 2025-07-10 03:27 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Fujii Masao <masao.fujii@oss.nttdata.com>; Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Wed, Jul 9, 2025 at 8:47 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Wed, 2025-07-09 at 19:19 +0900, Fujii Masao wrote:
> > On 2025/07/09 18:21, Laurenz Albe wrote:
> > > On Wed, 2025-07-09 at 07:24 +0000, Hayato Kuroda (Fujitsu) wrote:
> > > > >
> > > > Based on that, I want to propose the hybrid approach; use injection_point_attach()
> > > > if possible, otherwise wait few seconds. One concern is that the test code may be
> > > > bit complex, but below codes was enough on my environment.
> > > >
> > > > Attached patch implements the idea, which can be applied atop v2. How do you think?
> > >
> > > I have no objections.
> >
> > So the purpose of this "hybrid approach" is to test idle_replication_slot_timeout
> > even in environments where the injection point isn't available? Do we really need
> > this additional test? It seems to me that the test using the injection point is
> > sufficient.
>
> If you think that using the injection point is sufficient, go for it.
>
> That means slightly less test coverage; the injection point skips the call to
> TimestampDifferenceExceedsSeconds() to determine if the slot's "inactive_since"
> is old enough and just unconditionally returns RS_INVAL_IDLE_TIMEOUT.
> But yes, that is not a big loss.
>
> My patch has the advantage of
> a) simplifying the code,
> b) running the test even if injection points are not available and
> c) testing more of the code
> at the price of two extra seconds for the TAP tests.
>
I think an additional two seconds is not worth this test, especially
when we have another way to test most of it, and it could be
noticeable overhead for developers who need to run check-world
multiple times in a day. If we want to proceed with changing the
units, we can leave the existing test as it is. BTW, as mentioned
yesterday, I still feel keeping minutes as a unit for
idle_replication_slot_timeout has merits, but I surrender my case
based on what most other people feel is the right thing to do.
> The "hybrid approach" saves the two seconds on system with injection points,
> but cannot simplify the code.
>
I feel that would be a needless complexity in the test.
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 38+ messages in thread
* RE: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-10 05:27 Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
parent: Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Hayato Kuroda (Fujitsu) @ 2025-07-10 05:27 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Fujii Masao <masao.fujii@oss.nttdata.com>; Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
> > The "hybrid approach" saves the two seconds on system with injection points,
> > but cannot simplify the code.
> >
>
> I feel that would be a needless complexity in the test.
Yeah, it is the down side of the approach. If it do not have enough advantage, let's drop the idea.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-10 05:51 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
0 siblings, 1 reply; 38+ messages in thread
From: Laurenz Albe @ 2025-07-10 05:51 UTC (permalink / raw)
To: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Fujii Masao <masao.fujii@oss.nttdata.com>; Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Thu, 2025-07-10 at 05:27 +0000, Hayato Kuroda (Fujitsu) wrote:
> > > The "hybrid approach" saves the two seconds on system with injection points,
> > > but cannot simplify the code.
> >
> > I feel that would be a needless complexity in the test.
>
> Yeah, it is the down side of the approach. If it do not have enough advantage, let's drop the idea.
Great, then I think that we have consensus.
Let's change to seconds and leave the injectsion points and tests as they are.
I'd still like to see the documentation improved, like my patch tried to do.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-10 10:27 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 38+ messages in thread
From: Fujii Masao @ 2025-07-10 10:27 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 2025/07/10 14:51, Laurenz Albe wrote:
> On Thu, 2025-07-10 at 05:27 +0000, Hayato Kuroda (Fujitsu) wrote:
>>>> The "hybrid approach" saves the two seconds on system with injection points,
>>>> but cannot simplify the code.
>>>
>>> I feel that would be a needless complexity in the test.
>>
>> Yeah, it is the down side of the approach. If it do not have enough advantage, let's drop the idea.
>
> Great, then I think that we have consensus.
> Let's change to seconds and leave the injectsion points and tests as they are.
+1
> I'd still like to see the documentation improved, like my patch tried to do.
Agreed.
I created this as a separate patch from the one that changes the unit,
since they serve different purposes. Both patches are attached.
I'm planning to commit them.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From e7b834d91b67ea2d06cb9832ca51d70af5d008de Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Thu, 10 Jul 2025 17:42:04 +0900
Subject: [PATCH v3 1/2] Change unit of idle_replication_slot_timeout to
seconds.
Previously, the idle_replication_slot_timeout parameter used minutes
as its unit, based on the assumption that values would typically exceed
one minute in production environments. However, this caused unexpected
behavior: specifying a value below 30 seconds would round down to 0,
effectively disabling the timeout. This could be surprising to users.
To allow finer-grained control and avoid such confusion, this commit changes
the unit of idle_replication_slot_timeout to seconds. Larger values can
still be specified easily using standard time suffixes, for example,
'24h' for 24 hours.
Reported-by: Gunnar Morling <gunnar.morling@googlemail.com>
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com
---
doc/src/sgml/config.sgml | 2 +-
src/backend/replication/slot.c | 21 ++++++++-----------
src/backend/utils/misc/guc_tables.c | 6 +++---
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/include/replication/slot.h | 2 +-
5 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 59a0874528a..bd12225cbe4 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4620,7 +4620,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
<para>
Invalidate replication slots that have remained idle longer than this
duration. If this value is specified without units, it is taken as
- minutes. A value of zero (the default) disables the idle timeout
+ seconds. A value of zero (the default) disables the idle timeout
invalidation mechanism. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command
line.
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index f369fce2485..c1c0f6c660d 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -154,7 +154,7 @@ int max_replication_slots = 10; /* the maximum number of replication
* Invalidate replication slots that have remained idle longer than this
* duration; '0' disables it.
*/
-int idle_replication_slot_timeout_mins = 0;
+int idle_replication_slot_timeout_secs = 0;
/*
* This GUC lists streaming replication standby server slot names that
@@ -1612,13 +1612,10 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
case RS_INVAL_IDLE_TIMEOUT:
{
- int minutes = slot_idle_seconds / SECS_PER_MINUTE;
- int secs = slot_idle_seconds % SECS_PER_MINUTE;
-
/* translator: %s is a GUC variable name */
- appendStringInfo(&err_detail, _("The slot's idle time of %dmin %02ds exceeds the configured \"%s\" duration of %dmin."),
- minutes, secs, "idle_replication_slot_timeout",
- idle_replication_slot_timeout_mins);
+ appendStringInfo(&err_detail, _("The slot's idle time of %lds exceeds the configured \"%s\" duration of %ds."),
+ slot_idle_seconds, "idle_replication_slot_timeout",
+ idle_replication_slot_timeout_secs);
/* translator: %s is a GUC variable name */
appendStringInfo(&err_hint, _("You might need to increase \"%s\"."),
"idle_replication_slot_timeout");
@@ -1656,7 +1653,7 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
static inline bool
CanInvalidateIdleSlot(ReplicationSlot *s)
{
- return (idle_replication_slot_timeout_mins != 0 &&
+ return (idle_replication_slot_timeout_secs != 0 &&
!XLogRecPtrIsInvalid(s->data.restart_lsn) &&
s->inactive_since > 0 &&
!(RecoveryInProgress() && s->data.synced));
@@ -1717,9 +1714,9 @@ DetermineSlotInvalidationCause(uint32 possible_causes, ReplicationSlot *s,
if (CanInvalidateIdleSlot(s))
{
/*
- * We simulate the invalidation due to idle_timeout as the minimum
- * time idle time is one minute which makes tests take a long
- * time.
+ * Simulate the invalidation due to idle_timeout to test the
+ * timeout behavior promptly, without waiting for it to trigger
+ * naturally.
*/
#ifdef USE_INJECTION_POINTS
if (IS_INJECTION_POINT_ATTACHED("slot-timeout-inval"))
@@ -1734,7 +1731,7 @@ DetermineSlotInvalidationCause(uint32 possible_causes, ReplicationSlot *s,
* idle_replication_slot_timeout GUC.
*/
if (TimestampDifferenceExceedsSeconds(s->inactive_since, now,
- idle_replication_slot_timeout_mins * SECS_PER_MINUTE))
+ idle_replication_slot_timeout_secs))
{
*inactive_since = s->inactive_since;
return RS_INVAL_IDLE_TIMEOUT;
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 511dc32d519..a925be86944 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -3100,10 +3100,10 @@ struct config_int ConfigureNamesInt[] =
gettext_noop("Sets the duration a replication slot can remain idle before "
"it is invalidated."),
NULL,
- GUC_UNIT_MIN
+ GUC_UNIT_S
},
- &idle_replication_slot_timeout_mins,
- 0, 0, INT_MAX / SECS_PER_MINUTE,
+ &idle_replication_slot_timeout_secs,
+ 0, 0, INT_MAX,
check_idle_replication_slot_timeout, NULL, NULL
},
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 341f88adc87..a9d8293474a 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -342,7 +342,7 @@
# (change requires restart)
#wal_keep_size = 0 # in megabytes; 0 disables
#max_slot_wal_keep_size = -1 # in megabytes; -1 disables
-#idle_replication_slot_timeout = 0 # in minutes; 0 disables
+#idle_replication_slot_timeout = 0 # in seconds; 0 disables
#wal_sender_timeout = 60s # in milliseconds; 0 disables
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
diff --git a/src/include/replication/slot.h b/src/include/replication/slot.h
index ffacba9d2ae..76aeeb92242 100644
--- a/src/include/replication/slot.h
+++ b/src/include/replication/slot.h
@@ -266,7 +266,7 @@ extern PGDLLIMPORT ReplicationSlot *MyReplicationSlot;
/* GUCs */
extern PGDLLIMPORT int max_replication_slots;
extern PGDLLIMPORT char *synchronized_standby_slots;
-extern PGDLLIMPORT int idle_replication_slot_timeout_mins;
+extern PGDLLIMPORT int idle_replication_slot_timeout_secs;
/* shmem initialization functions */
extern Size ReplicationSlotsShmemSize(void);
--
2.49.0
From d3a91da817b7470ed19d486daffc0bf3334f58f9 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Thu, 10 Jul 2025 18:16:13 +0900
Subject: [PATCH v3 2/2] doc: Clarify meaning of "idle" in
idle_replication_slot_timeout.
This commit updates the documentation to clarify that "idle" in
idle_replication_slot_timeout means the replication slot is inactive,
that is, not currently used by any replication connection.
Without this clarification, "idle" could be misinterpreted to mean
that the slot is not advancing or that no data is being streamed,
even if a connection exists.
Author: Laurenz Albe <laurenz.albe@cybertec.at>
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
Reviewed-by: Gunnar Morling <gunnar.morling@googlemail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com
---
doc/src/sgml/config.sgml | 10 ++++++----
doc/src/sgml/system-views.sgml | 2 +-
src/backend/replication/slot.c | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index bd12225cbe4..c7acc0f182f 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4618,10 +4618,12 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</term>
<listitem>
<para>
- Invalidate replication slots that have remained idle longer than this
- duration. If this value is specified without units, it is taken as
- seconds. A value of zero (the default) disables the idle timeout
- invalidation mechanism. This parameter can only be set in the
+ Invalidate replication slots that have remained inactive (not used by
+ a <link linkend="protocol-replication">replication connection</link>)
+ for longer than this duration.
+ If this value is specified without units, it is taken as seconds.
+ A value of zero (the default) disables the idle timeout
+ invalidation mechanism. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command
line.
</para>
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index d3ff8c35738..4187191ea74 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -3003,7 +3003,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
<listitem>
<para>
<literal>idle_timeout</literal> means that the slot has remained
- idle longer than the configured
+ inactive longer than the configured
<xref linkend="guc-idle-replication-slot-timeout"/> duration.
</para>
</listitem>
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index c1c0f6c660d..281092279ac 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1892,7 +1892,7 @@ InvalidatePossiblyObsoleteSlot(uint32 possible_causes,
* max_slot_wal_keep_size is set to -1 and
* idle_replication_slot_timeout is set to 0 during the binary
* upgrade. See check_old_cluster_for_valid_slots() where we ensure
- * that no invalidated before the upgrade.
+ * that no slot was invalidated before the upgrade.
*/
Assert(!(*invalidated && SlotIsLogical(s) && IsBinaryUpgrade));
--
2.49.0
Attachments:
[text/plain] v3-0001-Change-unit-of-idle_replication_slot_timeout-to-s.patch (6.9K, ../../5fddbcc5-0c05-493d-a3f0-1fe49ffe5600@oss.nttdata.com/2-v3-0001-Change-unit-of-idle_replication_slot_timeout-to-s.patch)
download | inline diff:
From e7b834d91b67ea2d06cb9832ca51d70af5d008de Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Thu, 10 Jul 2025 17:42:04 +0900
Subject: [PATCH v3 1/2] Change unit of idle_replication_slot_timeout to
seconds.
Previously, the idle_replication_slot_timeout parameter used minutes
as its unit, based on the assumption that values would typically exceed
one minute in production environments. However, this caused unexpected
behavior: specifying a value below 30 seconds would round down to 0,
effectively disabling the timeout. This could be surprising to users.
To allow finer-grained control and avoid such confusion, this commit changes
the unit of idle_replication_slot_timeout to seconds. Larger values can
still be specified easily using standard time suffixes, for example,
'24h' for 24 hours.
Reported-by: Gunnar Morling <gunnar.morling@googlemail.com>
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com
---
doc/src/sgml/config.sgml | 2 +-
src/backend/replication/slot.c | 21 ++++++++-----------
src/backend/utils/misc/guc_tables.c | 6 +++---
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/include/replication/slot.h | 2 +-
5 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 59a0874528a..bd12225cbe4 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4620,7 +4620,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
<para>
Invalidate replication slots that have remained idle longer than this
duration. If this value is specified without units, it is taken as
- minutes. A value of zero (the default) disables the idle timeout
+ seconds. A value of zero (the default) disables the idle timeout
invalidation mechanism. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command
line.
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index f369fce2485..c1c0f6c660d 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -154,7 +154,7 @@ int max_replication_slots = 10; /* the maximum number of replication
* Invalidate replication slots that have remained idle longer than this
* duration; '0' disables it.
*/
-int idle_replication_slot_timeout_mins = 0;
+int idle_replication_slot_timeout_secs = 0;
/*
* This GUC lists streaming replication standby server slot names that
@@ -1612,13 +1612,10 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
case RS_INVAL_IDLE_TIMEOUT:
{
- int minutes = slot_idle_seconds / SECS_PER_MINUTE;
- int secs = slot_idle_seconds % SECS_PER_MINUTE;
-
/* translator: %s is a GUC variable name */
- appendStringInfo(&err_detail, _("The slot's idle time of %dmin %02ds exceeds the configured \"%s\" duration of %dmin."),
- minutes, secs, "idle_replication_slot_timeout",
- idle_replication_slot_timeout_mins);
+ appendStringInfo(&err_detail, _("The slot's idle time of %lds exceeds the configured \"%s\" duration of %ds."),
+ slot_idle_seconds, "idle_replication_slot_timeout",
+ idle_replication_slot_timeout_secs);
/* translator: %s is a GUC variable name */
appendStringInfo(&err_hint, _("You might need to increase \"%s\"."),
"idle_replication_slot_timeout");
@@ -1656,7 +1653,7 @@ ReportSlotInvalidation(ReplicationSlotInvalidationCause cause,
static inline bool
CanInvalidateIdleSlot(ReplicationSlot *s)
{
- return (idle_replication_slot_timeout_mins != 0 &&
+ return (idle_replication_slot_timeout_secs != 0 &&
!XLogRecPtrIsInvalid(s->data.restart_lsn) &&
s->inactive_since > 0 &&
!(RecoveryInProgress() && s->data.synced));
@@ -1717,9 +1714,9 @@ DetermineSlotInvalidationCause(uint32 possible_causes, ReplicationSlot *s,
if (CanInvalidateIdleSlot(s))
{
/*
- * We simulate the invalidation due to idle_timeout as the minimum
- * time idle time is one minute which makes tests take a long
- * time.
+ * Simulate the invalidation due to idle_timeout to test the
+ * timeout behavior promptly, without waiting for it to trigger
+ * naturally.
*/
#ifdef USE_INJECTION_POINTS
if (IS_INJECTION_POINT_ATTACHED("slot-timeout-inval"))
@@ -1734,7 +1731,7 @@ DetermineSlotInvalidationCause(uint32 possible_causes, ReplicationSlot *s,
* idle_replication_slot_timeout GUC.
*/
if (TimestampDifferenceExceedsSeconds(s->inactive_since, now,
- idle_replication_slot_timeout_mins * SECS_PER_MINUTE))
+ idle_replication_slot_timeout_secs))
{
*inactive_since = s->inactive_since;
return RS_INVAL_IDLE_TIMEOUT;
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 511dc32d519..a925be86944 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -3100,10 +3100,10 @@ struct config_int ConfigureNamesInt[] =
gettext_noop("Sets the duration a replication slot can remain idle before "
"it is invalidated."),
NULL,
- GUC_UNIT_MIN
+ GUC_UNIT_S
},
- &idle_replication_slot_timeout_mins,
- 0, 0, INT_MAX / SECS_PER_MINUTE,
+ &idle_replication_slot_timeout_secs,
+ 0, 0, INT_MAX,
check_idle_replication_slot_timeout, NULL, NULL
},
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 341f88adc87..a9d8293474a 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -342,7 +342,7 @@
# (change requires restart)
#wal_keep_size = 0 # in megabytes; 0 disables
#max_slot_wal_keep_size = -1 # in megabytes; -1 disables
-#idle_replication_slot_timeout = 0 # in minutes; 0 disables
+#idle_replication_slot_timeout = 0 # in seconds; 0 disables
#wal_sender_timeout = 60s # in milliseconds; 0 disables
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
diff --git a/src/include/replication/slot.h b/src/include/replication/slot.h
index ffacba9d2ae..76aeeb92242 100644
--- a/src/include/replication/slot.h
+++ b/src/include/replication/slot.h
@@ -266,7 +266,7 @@ extern PGDLLIMPORT ReplicationSlot *MyReplicationSlot;
/* GUCs */
extern PGDLLIMPORT int max_replication_slots;
extern PGDLLIMPORT char *synchronized_standby_slots;
-extern PGDLLIMPORT int idle_replication_slot_timeout_mins;
+extern PGDLLIMPORT int idle_replication_slot_timeout_secs;
/* shmem initialization functions */
extern Size ReplicationSlotsShmemSize(void);
--
2.49.0
[text/plain] v3-0002-doc-Clarify-meaning-of-idle-in-idle_replication_s.patch (3.4K, ../../5fddbcc5-0c05-493d-a3f0-1fe49ffe5600@oss.nttdata.com/3-v3-0002-doc-Clarify-meaning-of-idle-in-idle_replication_s.patch)
download | inline diff:
From d3a91da817b7470ed19d486daffc0bf3334f58f9 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Thu, 10 Jul 2025 18:16:13 +0900
Subject: [PATCH v3 2/2] doc: Clarify meaning of "idle" in
idle_replication_slot_timeout.
This commit updates the documentation to clarify that "idle" in
idle_replication_slot_timeout means the replication slot is inactive,
that is, not currently used by any replication connection.
Without this clarification, "idle" could be misinterpreted to mean
that the slot is not advancing or that no data is being streamed,
even if a connection exists.
Author: Laurenz Albe <laurenz.albe@cybertec.at>
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
Reviewed-by: Gunnar Morling <gunnar.morling@googlemail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com
---
doc/src/sgml/config.sgml | 10 ++++++----
doc/src/sgml/system-views.sgml | 2 +-
src/backend/replication/slot.c | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index bd12225cbe4..c7acc0f182f 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4618,10 +4618,12 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</term>
<listitem>
<para>
- Invalidate replication slots that have remained idle longer than this
- duration. If this value is specified without units, it is taken as
- seconds. A value of zero (the default) disables the idle timeout
- invalidation mechanism. This parameter can only be set in the
+ Invalidate replication slots that have remained inactive (not used by
+ a <link linkend="protocol-replication">replication connection</link>)
+ for longer than this duration.
+ If this value is specified without units, it is taken as seconds.
+ A value of zero (the default) disables the idle timeout
+ invalidation mechanism. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command
line.
</para>
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index d3ff8c35738..4187191ea74 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -3003,7 +3003,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
<listitem>
<para>
<literal>idle_timeout</literal> means that the slot has remained
- idle longer than the configured
+ inactive longer than the configured
<xref linkend="guc-idle-replication-slot-timeout"/> duration.
</para>
</listitem>
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index c1c0f6c660d..281092279ac 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1892,7 +1892,7 @@ InvalidatePossiblyObsoleteSlot(uint32 possible_causes,
* max_slot_wal_keep_size is set to -1 and
* idle_replication_slot_timeout is set to 0 during the binary
* upgrade. See check_old_cluster_for_valid_slots() where we ensure
- * that no invalidated before the upgrade.
+ * that no slot was invalidated before the upgrade.
*/
Assert(!(*invalidated && SlotIsLogical(s) && IsBinaryUpgrade));
--
2.49.0
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-10 11:58 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 38+ messages in thread
From: Laurenz Albe @ 2025-07-10 11:58 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Thu, 2025-07-10 at 19:27 +0900, Fujii Masao wrote:
> I created this as a separate patch from the one that changes the unit,
> since they serve different purposes. Both patches are attached.
> I'm planning to commit them.
Your Patches look good for me.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-10 23:48 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 38+ messages in thread
From: Fujii Masao @ 2025-07-10 23:48 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 2025/07/10 20:58, Laurenz Albe wrote:
> On Thu, 2025-07-10 at 19:27 +0900, Fujii Masao wrote:
>> I created this as a separate patch from the one that changes the unit,
>> since they serve different purposes. Both patches are attached.
>> I'm planning to commit them.
>
> Your Patches look good for me.
Thanks for the review! I've pushed both patches.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-11 02:32 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 38+ messages in thread
From: Laurenz Albe @ 2025-07-11 02:32 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; Gunnar Morling <gunnar.morling@googlemail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Fri, 2025-07-11 at 08:48 +0900, Fujii Masao wrote:
> Thanks for the review! I've pushed both patches.
Thank you for taking care of this!
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 38+ messages in thread
* Re: Unexpected behavior when setting "idle_replication_slot_timeout"
@ 2025-07-11 06:57 Gunnar Morling <gunnar.morling@googlemail.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 0 replies; 38+ messages in thread
From: Gunnar Morling @ 2025-07-11 06:57 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; Amit Kapila <amit.kapila16@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; David G. Johnston <david.g.johnston@gmail.com>; Nisha Moond <nisha.moond412@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Thanks a lot to you Fujii, and everyone else, for addressing this!
--Gunnar
On Fri, 11 Jul 2025 at 04:32, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> On Fri, 2025-07-11 at 08:48 +0900, Fujii Masao wrote:
> > Thanks for the review! I've pushed both patches.
>
> Thank you for taking care of this!
>
> Yours,
> Laurenz Albe
>
^ permalink raw reply [nested|flat] 38+ messages in thread
end of thread, other threads:[~2025-07-11 06:57 UTC | newest]
Thread overview: 38+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-07-04 09:54 Unexpected behavior when setting "idle_replication_slot_timeout" Gunnar Morling <gunnar.morling@googlemail.com>
2025-07-04 12:14 ` Nisha Moond <nisha.moond412@gmail.com>
2025-07-04 14:12 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-04 15:22 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-04 16:07 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-04 16:24 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-04 18:59 ` Gunnar Morling <gunnar.morling@googlemail.com>
2025-07-04 22:08 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-05 04:06 ` Amit Kapila <amit.kapila16@gmail.com>
2025-07-05 14:44 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-05 15:10 ` David G. Johnston <david.g.johnston@gmail.com>
2025-07-05 15:56 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-07-05 16:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-07-08 16:42 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-08 16:53 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-09 06:35 ` Amit Kapila <amit.kapila16@gmail.com>
2025-07-09 07:12 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-09 07:24 ` Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
2025-07-09 09:21 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-09 10:19 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-09 15:17 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-10 03:27 ` Amit Kapila <amit.kapila16@gmail.com>
2025-07-10 05:27 ` Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
2025-07-10 05:51 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-10 10:27 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-10 11:58 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-10 23:48 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-11 02:32 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-11 06:57 ` Gunnar Morling <gunnar.morling@googlemail.com>
2025-07-09 06:00 ` Amit Kapila <amit.kapila16@gmail.com>
2025-07-05 04:22 ` Amit Kapila <amit.kapila16@gmail.com>
2025-07-05 05:35 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-05 05:55 ` David G. Johnston <david.g.johnston@gmail.com>
2025-07-05 06:16 ` David G. Johnston <david.g.johnston@gmail.com>
2025-07-05 08:47 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-07-05 14:38 ` David G. Johnston <david.g.johnston@gmail.com>
2025-07-05 15:07 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-05 15:12 ` David G. Johnston <david.g.johnston@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox