Re: PostgreSQL shutdown modes
От | chap@anastigmatix.net |
---|---|
Тема | Re: PostgreSQL shutdown modes |
Дата | |
Msg-id | 646fd55b77c352434ffa1e272b3b110e@anastigmatix.net обсуждение исходный текст |
Ответ на | PostgreSQL shutdown modes (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: PostgreSQL shutdown modes
|
Список | 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 по дате отправления: