On Tue, Nov 22, 2016 at 10:59 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
