On Mon, Feb 17, 2025 at 07:57:22AM +0530, Amit Kapila wrote:
> On Wed, Feb 12, 2025 at 1:16 PM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
>> On Wednesday, February 12, 2025 11:56 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>> > Also, we previously didn't have a good experience with XID-based threshold
>> > parameters like vacuum_defer_cleanup_age as mentioned by Robert (1).
>> > AFAICU from the previous discussion we need a time-based parameter and we
>> > didn't rule out xid_age based parameter as another parameter.
I am not sure I buy the comparison with vacuum_defer_cleanup_age. That is
a very different feature than max_slot_xid_age, and we still have a number
of XID-based parameters (vacuum_freeze_table_age, vacuum_freeze_min_age,
vacuum_failsafe_age, the multixact versions of those parameters, and the
autovacuum versions).
>> Yeah, I think the primary purpose of this time-based option is to invalidate dormant
>> replication slots that have been inactive for a long period, in which case the
>> slots are no longer useful.
>>
>> Such slots can remain if a subscriber is down due to a system error or
>> inaccessible because of network issues. If this situation persists, it might be
>> more practical to recreate the subscriber rather than attempt to recover the
>> node and wait for it to catch up, which could be time-consuming.
>>
>> Parameters like max_slot_wal_keep_size and max_slot_xid_id_age do not
>> differentiate between active and inactive replication slots. Some customers I
>> met are hesitant about using these settings, as they can sometimes invalidate
>> a slot unnecessarily and break the replication.
Sure, an inactive-timeout feature won't break replication, but it's also
not going to be terribly effective against wraparound-related issues. It
seems weird to me to allow an active replication slot to take priority over
imminent storage/XID issues it causes.
> Alvaro, Nathan, do let us know if you would like to discuss more on
> the use case for this new GUC idle_replication_slot_timeout?
> Otherwise, we can proceed with this patch.
I guess I'm not mortally opposed to it. I just think we really need
proper backstops against the storage/XID issues more than we need this one,
and I don't want it to be mistaken for a solution to those problems.
--
nathan
