On Tue, Nov 22, 2016 at 10:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's already the case that the pgstats code writes the stats data under a
> temporary file name and then renames it into place atomically. So the
> prospects for corrupt data are not large, and I do not think that the
> existing removal behavior was intended to prevent that. Rather, the
> concern was that if you do a point-in-time recovery to someplace much
> earlier on the WAL timeline, the stats file will be out of sync with
> what's now in your database. That's a valid point, but deleting the
> stats file during *any* recovery seems like an overreaction.
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?
I think that the charter of an immediate shutdown is to perform a
simulated crash. We do our best to let clients know that we are going
down and then we go down. We don't checkpoint, we don't do any other
operation that might take a lengthy period of time, we just SHUT DOWN.
You're arguing that preserving the stats file is more important than
timely shutdown, but I don't buy it. We've never tried to do that in
the past and we've got no evidence that it's causing a problem for
anyone. Yeah, it's not good, but neither are the things that prompt
people to perform an immediate shutdown in the first place.
On the other hand, there's plenty of evidence that slow shutdowns are
a big problem for users. People use fast shutdown because smart
shutdown was too slow (never-ending), and we changed the default for
that reason. I've repeatedly seen users who resorted to an immediate
shut down because a fast shutdown wasn't fast enough. 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
it's fairly perverse to receive yet another complaint about shutdown
being slow and, instead of fixing it, go try to make sure that
slowness is baked in as a policy decision.
Immediate, adj. occurring or done at once; instant.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
