"George Pavlov" <gpavlov@xxxxxxxxxxxxxx> writes: > i have examined the stop() and start() and i think i understand why the > stop() reported a failure (it took to long), but i don't understand how > the start() could have reported success: >> Stopping postgresql service: [FAILED] >> Starting postgresql service: [ OK ] Well, that makes sense: if the shutdown took more than a minute then the "stop" script action would give up waiting, and then the "start" action would see the postmaster running and go away happy. (It's a bit odd that "service start" actions are supposed to treat "already running" as OK, but I've been told that that's required by the Linux Standards Base and I can't change it.) The real question here is why'd it take so long to stop? It should be using "mode fast" which'd kick out active queries. >> Just out of curiosity, what for? I can't imagine any really >> good reason >> for just shutting down the postmaster and immediately restarting it. > why have a "restart" option if there is never a reason for it? :-) Well, there are times when you need it, like changing shared_buffers or one of the other postmaster-start-time-only parameters. But doing it just as a routine action smacks of Microsoftish "you need to reboot regularly" thinking... > seriously, this is a good question, i think this was someone's idea of a > quick way to clear any remaining DB sessions in order to be able to drop > a database and restore a newer version (this is a reporting DB that gets > refreshed nightly with a dump from another DB). Hmm. It's not exactly bulletproof --- what if someone reconnects to the DB as soon as you restart? But I guess it's a simple answer that might not be worth improving on. regards, tom lane