On Sat, Apr 2, 2022 at 9:39 AM <chap@anastigmatix.net> wrote:
> 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.
Yeah. While the patch itself is mostly in jest, everything I wrote in
the email is unfortunately pretty much 100% accurate, no fooling. I
think it would be worth doing a number of things:
- Provide some way of backing out of smart shutdown mode.
- Provide some way of making a smart shutdown turn into a fast
shutdown after a configurable period of time.
- Do a preparatory checkpoint before the real shutdown checkpoint
especially in fast mode, but maybe also in smart mode. Maybe there's
some even smarter thing we could be doing here, not sure what exactly.
- Consider renaming "immediate" mode, maybe to "crash" or something.
Oracle uses "abort".
> 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).
Seems like this might be better done in user-space than hard-coded
into the server behavior.
--
Robert Haas
EDB: http://www.enterprisedb.com
