Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: > ISTM that this would change the "immediate shutdown" to not save stats > files anymore. So far, all the shutdown modes are equivalent in terms > of how they preserve data and system state. They differ only in when > the hard work happens. This would be a deviation from that principle.
There is that. Up to now, an immediate shutdown request didn't cause any actual data loss, but now it would. Maybe that's a reason to reject this whole concept. (Upthread I was thinking that's a behavior we have anyway, but really we don't: a look through pgstats.c shows that it will never exit without attempting to write the stats, short of a crash of the stats collector process itself.) > Child processes don't distinguish between a SIGQUIT coming from a > user-initiated immediate shutdown request and a crash-induced > kill-everyone directive. So there might not be a non-ugly way to > address that. It doesn't seem to me that it's a matter of whether the signaling is adequate; we could fix that. It's a matter of whether you're willing to have "pg_ctl stop -m immediate" lose stats data. Although the stats collector was originally conceived as optional, we depend on it enough now for autovacuum that I'm not sure it'd be a good thing to have a popularly-used shutdown mode that loses the stats. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers