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

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Nisha Moond <nisha.moond412@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Peter Smith <smithpb2250@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, shveta malik <shveta.malik@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Ajin Cherian <itsajin@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-02-06T04:47:05Z
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

Attachments

On Thu, Feb 6, 2025 at 8:02 AM Nisha Moond <nisha.moond412@gmail.com> wrote:
>
> On Wed, Feb 5, 2025 at 2:42 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > Would it address your concern if we write the actual idle duration
> > (now - inactive_since) instead of directly using inactive_since in the
> > above message?
> >
>
> Simply using the raw timestamp difference (now - inactive_since) would
> look odd. We should convert it into a user-friendly format. Since
> idle_replication_slot_timeout is in minutes, we can express the
> difference in minutes and seconds in the log.
> For example:
> DETAIL: The slot's idle time of 1 minute and 7 seconds exceeds the
> configured "idle_replication_slot_timeout" duration.
>

This is better but the implementation should be done on the caller
side mainly because we don't want to call a new GetCurrentTimestamp()
in ReportSlotInvalidation.

>
> > 2.
> > + * Flush all replication slots to disk. Also, invalidate obsolete slots during
> > + * non-shutdown checkpoint.
> >   *
> >   * It is convenient to flush dirty replication slots at the time of checkpoint.
> >   * Additionally, in case of a shutdown checkpoint, we also identify the slots
> > @@ -1924,6 +2007,45 @@ CheckPointReplicationSlots(bool is_shutdown)
> >
> > Can we try and see how the patch looks if we try to invalidate the
> > slot due to idle time at the same time when we are trying to
> > invalidate due to WAL?
> >
>
> I'll consider the suggested change in the next version.
>

FYI, we discussed this previously (1), but the conclusion that it
won't help much (as it will not help to remove WAL immediately) is
incorrect, especially if we do what is suggested now.

Apart from this, I have made minor changes in the comments. Please
review and include them unless you disagree.

(1) - https://www.postgresql.org/message-id/CALj2ACXe8%2BxSNdMXTMaSRWUwX7v61Ad4iddUwnn%3DdjSwx3GLLg%40mail.gmail.com


-- 
With Regards,
Amit Kapila.