From: Nathan Bossart <nathandbossart@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: shveta malik <shveta.malik@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Amit Kapila <akapila@postgresql.org>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Track last_inactive_time in pg_replication_slots.
Date: Tue, 26 Mar 2024 10:09:18 -0500
Message-ID: <20240326150918.GB3181099@nathanxps13> (raw)
In-Reply-To: <CAA4eK1+SLfHrS_haOvD5oXk6cwD9Szh8BYR5MpPRJaBDMaELXA@mail.gmail.com>
References: <CAA4eK1Kbu-HvRMori=ujKAN1SZ2ixJ5ioFNOGpfR4xU-SENULw@mail.gmail.com>
<202403260841.5jcv7ihniccy@alvherre.pgsql>
<CAA4eK1+SLfHrS_haOvD5oXk6cwD9Szh8BYR5MpPRJaBDMaELXA@mail.gmail.com>
On Tue, Mar 26, 2024 at 03:44:29PM +0530, Amit Kapila wrote:
> On Tue, Mar 26, 2024 at 2:11 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> Well, I think a GUC is good to have regardless of the slot parameter,
>> because the GUC can be used as an instance-wide protection against going
>> out of disk space because of broken replication. However, now that I
>> think about it, I'm not really sure about invalidating a slot based on
>> time rather on disk space, for which we already have a parameter; what's
>> your rationale for that? The passage of time is not a very good
>> measure, really, because the amount of WAL being protected has wildly
>> varying production rate across time.
>
> The inactive slot not only blocks WAL from being removed but prevents
> the vacuum from proceeding. Also, there is a risk of transaction Id
> wraparound. See email [1] for more context.
FWIW I'd really prefer to have something like max_slot_xid_age for this. A
time-based parameter would likely help with most cases, but transaction ID
usage will vary widely from server to server, so it'd be nice to have
something to protect against wraparound more directly. I don't object to a
time-based setting as well, but that won't always work as well for this
particular use-case, especially if we are relying on users to set a
slot-level parameter.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
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: pgsql-committers@postgresql.org
Cc: nathandbossart@gmail.com, amit.kapila16@gmail.com, alvherre@alvh.no-ip.org, robertmhaas@gmail.com, bertranddrouvot.pg@gmail.com, shveta.malik@gmail.com, bharath.rupireddyforpostgres@gmail.com, akapila@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: pgsql: Track last_inactive_time in pg_replication_slots.
In-Reply-To: <20240326150918.GB3181099@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox