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 | CAA4eK1K8wqLsMw6j0hE_SFoWAeo3Kw8UNnMfhsWaYDF1GWYQ+g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Introduce XID age and inactive timeout based replication slot invalidation (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Introduce XID age and inactive timeout based replication slot invalidation
Re: Introduce XID age and inactive timeout based replication slot invalidation |
Список | pgsql-hackers |
On Wed, Mar 6, 2024 at 2:47 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > Thanks. v8-0001 is how it looks. Please see the v8 patch set with this change. > Commit message says: "Currently postgres has the ability to invalidate inactive replication slots based on the amount of WAL (set via max_slot_wal_keep_size GUC) that will be needed for the slots in case they become active. However, choosing a default value for max_slot_wal_keep_size is tricky. Because the amount of WAL a customer generates, and their allocated storage will vary greatly in production, making it difficult to pin down a one-size-fits-all value. It is often easy for developers to set an XID age (age of slot's xmin or catalog_xmin) of say 1 or 1.5 billion, after which the slots get invalidated." I don't see how it will be easier for the user to choose the default value of 'max_slot_xid_age' compared to 'max_slot_wal_keep_size'. But, I agree similar to 'max_slot_wal_keep_size', 'max_slot_xid_age' can be another parameter to allow vacuum to proceed removing the rows which otherwise it wouldn't have been as those would be required by some slot. Now, if this understanding is correct, we should probably make this invalidation happen by (auto)vacuum after computing the age based on this new parameter. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: