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.f...@fujitsu.com> wrote: >> On Wednesday, February 12, 2025 11:56 AM Amit Kapila >> <amit.kapil...@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
