Horton

Re: pgsql: Track last_inactive_time in pg_replication_slots.

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, shveta malik <shveta.malik@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Amit Kapila <akapila@postgresql.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-03-26T15:39:55Z
Lists: pgsql-hackers 
On 2024-Mar-26, Nathan Bossart wrote:

> 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.

Yeah, I tend to agree that an XID-based limit makes more sense than a
time-based one.

> 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.

I think slot-level parameters are mostly useless, because it takes just
one slot where you forget to set it for disaster to strike.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

Commits

  1. Allow synced slots to have their inactive_since.

  2. Change last_inactive_time to inactive_since in pg_replication_slots.

  3. Track last_inactive_time in pg_replication_slots.

  4. Remove vacuum_defer_cleanup_age