Re: Introduce XID age and inactive timeout based replication slot invalidation
От | Amit Kapila |
---|---|
Тема | Re: Introduce XID age and inactive timeout based replication slot invalidation |
Дата | |
Msg-id | CAA4eK1+p5gj3508qF+47OS0CwEveSf6ufD6sPz4DxrfWWLA=2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Introduce XID age and inactive timeout based replication slot invalidation (Nathan Bossart <nathandbossart@gmail.com>) |
Список | pgsql-hackers |
On Tue, Mar 26, 2024 at 1:24 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > > On Sun, Mar 24, 2024 at 03:05:44PM +0530, Bharath Rupireddy wrote: > > This commit particularly lets one specify the inactive_timeout for > > a slot via SQL functions pg_create_physical_replication_slot and > > pg_create_logical_replication_slot. > > Off-list, Bharath brought to my attention that the current proposal was to > set the timeout at the slot level. While I think that is an entirely > reasonable thing to support, the main use-case I have in mind for this > feature is for an administrator that wants to prevent inactive slots from > causing problems (e.g., transaction ID wraparound) on a server or a number > of servers. For that use-case, I think a GUC would be much more > convenient. Perhaps there could be a default inactive slot timeout GUC > that would be used in the absence of a slot-level setting. Thoughts? > Yeah, that is a valid point. One of the reasons for keeping it at slot level was to allow different subscribers/output plugins to have a different setting for invalid_timeout for their respective slots based on their usage. Now, having it as a GUC also has some valid use cases as pointed out by you but I am not sure having both at slot level and at GUC level is required. I was a bit inclined to have it at slot level for now and then based on some field usage report we can later add GUC as well. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: