Re: PG service restart failure (start getting ahead of stop?)

"George Pavlov" <gpavlov(at)mynewplace(dot)com> 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