Maciek Sakrejda <msakrejda@xxxxxxxxxxx> wrote: >>> Well.... it said "Failed to shutdown ..............." and then >>> returned control. and then proceeded to run for about an hour. >>> I'm not sure how graceful that is. >> >> Ah, but that was just the control script that sends the database >> the command to shut down. The 'graceful' part, is that the >> database is being nice to everyone trying to do things with the >> data inside. >> >> The control script has a timeout. So it'll send the command, wait >> a few seconds to see if the database responds, and then gives up. > > For what it's worth, I think that's the not-so-graceful part. The > control script gives up, but the actual shutdown still occurs > eventually, after all current connections have ended. I think most > users will take pg_ctl at its word, and assume "Failed to > shutdown" means "I couldn't shut down with this command, maybe you > should try something else", and not "I couldn't shut down right > now, although I'll get to it as soon as everyone disconnects.". Yeah, current behavior with that shutdown option is the opposite of smart for any production environment I've seen. (I can see where it would be handy in development, though.) What's best in production is the equivalent of the fast option with escalation to immediate if necessary to ensure shutdown within the time limit. In my world, telling PostgreSQL to shut down PostgreSQL is most often because in a few minutes someone is going to pull the plug to move the server, an electrician is going to flip the circuit off to do some wiring, or (in one recent event) the building is on fire and the fire department is about to cut electrical power. In such situations, patiently waiting for a long-running query to complete is a Very Bad Idea, much less waiting for a connection pool to cycle all connections out. Telling the user that the shutdown failed, when what is really happening is that it will block new connections and keep waiting around indefinitely, with an actual shutdown at some ill-defined future moment is adding insult to injury. In my view, anyway.... -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
