Re: PostgreSQL shutdown modes - Mailing list pgsql-hackers

From chap@anastigmatix.net
Subject Re: PostgreSQL shutdown modes
Date
Msg-id 646fd55b77c352434ffa1e272b3b110e@anastigmatix.net
Whole thread Raw
In response to PostgreSQL shutdown modes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PostgreSQL shutdown modes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2022-04-01 13:22, Robert Haas wrote:
> I attach herewith a modest patch to rename these shutdown modes to
> more accurately correspond to their actual characteristics.

I've waited for April 2nd to submit this comment, but it seemed to me 
that the
suggestion about the first-pass checkpoint in 'slow' mode is a 
no-foolin' good one.
Then I wondered whether there could be an option to accompany the 'dumb' 
mode that
would take a WHERE clause, to be implicitly applied to pg_stat_activity, 
whose
purpose would be to select those sessions that are ok to evict without 
waiting for
them to exit. It could recognize, say, backend connections in no current 
transaction
that are from your pesky app or connection pooler that holds things 
open. It could
also, for example, select things in transaction state but where
  current_timestamp - state_change > '5 minutes' (so it would be 
re-evaluated every
so often until ready to shut down).

For conciseness (and sanity), maybe the WHERE clause could be implicitly 
applied,
not to pg_stat_activity directly, but to a (virtual or actual) view that 
has
already been restricted to client backend sessions, and already has a 
column
for current_timestamp - state_change.

Regards,
-Chap



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [PATCH] pgbench: add multiconnect option
Next
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] Add extra statistics to explain for Nested Loop