Horton

Re: Introduce XID age and inactive timeout based replication slot invalidation

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-21T03:37:18Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add a test for commit ac0e33136a using the injection point.

  2. Invalidate inactive replication slots.

  3. Fix incorrect slot type in BuildTupleHashTableExt

  4. Allow synced slots to have their inactive_since.

  5. Change last_inactive_time to inactive_since in pg_replication_slots.

  6. Track last_inactive_time in pg_replication_slots.

  7. Track invalidation_reason in pg_replication_slots.

  8. Add option force_initdb to PostgreSQL::Test::Cluster:init()

  9. Add a failover option to subscriptions.

  10. Allow setting failover property in the replication command.

  11. Allow to enable failover property for replication slots via SQL API.

  12. Track conflict_reason in pg_replication_slots.

  13. Log messages for replication slot acquisition and release.

  14. Remove vacuum_defer_cleanup_age

  15. Fix corruption due to vacuum_defer_cleanup_age underflowing 64bit xids

  16. meson: Add initial version of meson based build system

On Thu, Mar 21, 2024 at 5:19 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Wed, Mar 20, 2024 at 7:08 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> >
> > Regarding v12-0004: "Allow setting inactive_timeout in the replication command",
> > shouldn't we also add an new SQL API say: pg_alter_replication_slot() that would
> > allow to change the timeout property?
> >
> > That would allow users to alter this property without the need to make a
> > replication connection.
>
> +1 to add a new SQL function pg_alter_replication_slot().
>

I also don't see any obvious problem with such an API. However, this
is not a good time to invent new APIs. Let's keep the feature simple
and then we can extend it in the next version after more discussion
and probably by that time we will get some feedback from the field as
well.

>
> It helps
> first create the slots and then later decide the appropriate
> inactive_timeout. It might grow into altering other slot parameters
> such as failover (I'm not sure if altering failover property on the
> primary after a while makes it the right candidate for syncing on the
> standby). Perhaps, we can add it for altering just inactive_timeout
> for now and be done with it.
>
> FWIW, ALTER_REPLICATION_SLOT was added keeping in mind just the
> failover property for logical slots, that's why it emits an error
> "cannot use ALTER_REPLICATION_SLOT with a physical replication slot"
>
> > But the issue is that it would make it inconsistent with the new inactivetimeout
> > in the subscription that is added in "v12-0005".
>
> Can you please elaborate what the inconsistency it causes with inactivetimeout?
>

I think the inconsistency can arise from the fact that on publisher
one can change the inactive_timeout for the slot corresponding to a
subscription but the subscriber won't know, so it will still show the
old value. If we want we can document this as a limitation and let
users be aware of it. However, I feel at this stage, let's not even
expose this from the subscription or maybe we can discuss it once/if
we are done with other patches. Anyway, if one wants to use this
feature with a subscription, she can create a slot first on the
publisher with inactive_timeout value and then associate such a slot
with a required subscription.

-- 
With Regards,
Amit Kapila.