public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bharath Rupireddy <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Bertrand Drouvot <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
Date: Tue, 12 Mar 2024 22:09:48 +0530
Message-ID: <CALj2ACUNDR==n6ebq86ShBqdf64EasANuxmXQBDYHDHeN3G5Fg@mail.gmail.com> (raw)
In-Reply-To: <CAA4eK1+C3QxAZ6UtpSn9umGB33YjtYJgxA_xVXCacATEfZG4YQ@mail.gmail.com>
References: <CALj2ACWgACB4opnbqi=x7Hc4aqcgkXoLsh1VB+gfidXaDQNu_Q@mail.gmail.com>
<CALj2ACWE9asmvN1B18LqfHE8uBuWGsCEP7OO5trRCxPtTPeHVA@mail.gmail.com>
<[email protected]>
<CALj2ACWbR9ck1PKyqT2agd2XCEq8L=D=X1Uw566yhA9SgXspAw@mail.gmail.com>
<20240301221108.GB3024365@nathanxps13>
<CALj2ACUprrvq=R9WBnCEtguBhSp0X+krTCGDvkHyBdawyex-kA@mail.gmail.com>
<20240303214434.GA3036597@nathanxps13>
<[email protected]>
<CALj2ACXBz9HG767ink9nQdz0n6EdZz5g_qutek2ffTP6LNDbGw@mail.gmail.com>
<20240305194443.GA3481820@nathanxps13>
<[email protected]>
<CALj2ACWgm++=TkXWo9spm+7ibGxcYL3SsYtT4tbW3=HT1VYs0Q@mail.gmail.com>
<CAA4eK1K28TybqsG9hEP4OaV4OrK__-3E35y5QYW-867p-Ur5gw@mail.gmail.com>
<CALj2ACV+gMb_AWzVCinwyQHi6uyOFMF4x60=B3Y5Zp9uq+H6Gw@mail.gmail.com>
<CAA4eK1+C3QxAZ6UtpSn9umGB33YjtYJgxA_xVXCacATEfZG4YQ@mail.gmail.com>
On Mon, Mar 11, 2024 at 3:44 PM Amit Kapila <[email protected]> wrote:
>
> Yes, your understanding is correct. I wanted us to consider having new
> parameters like 'inactive_replication_slot_timeout' to be at
> slot-level instead of GUC. I think this new parameter doesn't seem to
> be the similar as 'max_slot_wal_keep_size' which leads to truncation
> of WAL at global and then invalidates the appropriate slots. OTOH, the
> 'inactive_replication_slot_timeout' doesn't appear to have a similar
> global effect.
last_inactive_at is tracked for each slot using which slots get
invalidated based on inactive_replication_slot_timeout. It's like
max_slot_wal_keep_size invalidating slots based on restart_lsn. In a
way, both are similar, right?
> The other thing we should consider is what if the
> checkpoint happens at a timeout greater than
> 'inactive_replication_slot_timeout'?
In such a case, the slots get invalidated upon the next checkpoint as
the (current_checkpointer_timeout - last_inactive_at) will then be
greater than inactive_replication_slot_timeout.
> Shall, we consider doing it via
> some other background process or do we think checkpointer is the best
> we can have?
The same problem exists if we do it with some other background
process. I think the checkpointer is best because it already
invalidates slots for wal_removed cause, and flushes all replication
slots to disk. Moving this new invalidation functionality into some
other background process such as autovacuum will not only burden that
process' work but also mix up the unique functionality of that
background process.
Having said above, I'm open to ideas from others as I'm not so sure if
there's any issue with checkpointer invalidating the slots for new
reasons.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
view thread (32+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
In-Reply-To: <CALj2ACUNDR==n6ebq86ShBqdf64EasANuxmXQBDYHDHeN3G5Fg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox