Robert Haas <robertmh...@gmail.com> writes:
> But that's not what is at issue here. The issue is whether, when
> asked to exit immediately, all processes should exit immediately, or
> whether it would be better for all processes except one to exit
> immediately and the last one exit non-immediately. In other words,
> when the user asks for an immediate shutdown, do they really mean it,
> or are they OK taking time to do some other stuff first?
Peter already gave the response to that, which is that users do not
expect an immediate shutdown to have permanent harmful effects.
It doesn't have such effects so far as the SQL data goes; why is it
okay to blow away statistical data?
> You're arguing that preserving the stats file is more important than
> timely shutdown, but I don't buy it.
Yes, I am, and I disagree with you. The current decision on this point
was made ages ago, before autovacuum even existed let alone relied on
the stats for proper functioning. The tradeoff you're saying you're
okay with is "we'll shut down a few seconds faster, but you're going
to have table bloat problems later because autovacuum won't know it
needs to do anything". I wonder how many of the complaints we get
about table bloat are a consequence of people not realizing that
"pg_ctl stop -m immediate" is going to cost them.
> ... Yeah, it's not good, but neither are the things that prompt
> people to perform an immediate shutdown in the first place.
Really? I think many users think an immediate shutdown is just fine.
> The patch that
> you claim moots this one was inspired by immediate shutdowns taking
> too long, and that patch enjoyed pretty broad support IIRC.
I think that's historical revisionism. The commit message for 82233ce7e
says "(This might happen, for example, if a backend gets tangled trying
to malloc() due to gettext(), as in an example illustrated by MauMau.)".
There is absolutely nothing in it about people being dissatisfied with
the shutdown timing in normal cases; rather, it was done to prevent
cases where shutdown failed to happen at all.
regards, tom lane
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: