Re: [GENERAL] Shutting down a warm standby database in 8.2beta3
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] Shutting down a warm standby database in 8.2beta3 |
Дата | |
Msg-id | 7456.1164040831@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] Shutting down a warm standby database in 8.2beta3 ("Magnus Hagander" <mha@sollentuna.net>) |
Список | pgsql-hackers |
"Magnus Hagander" <mha@sollentuna.net> writes: > However, for this specific case we might be able to do something. pg_ctl > creates a job object that it assigns the postmaster to when it's started > if that works. (Won't work if pg_ctl itself is running inside a job > object, but normally it won't be doing that). That means that we could > have pg_ctl look up this job object and execute TerminateJobObject() on > it. That will kill all processes inside the job object (includnig > backends, but if we run it from pg_ctl *after* postmaster has shut down, > there should be none of those left). That would take care of cleaning up any scripts after the postmaster has already quit, but what about the problem of kicking the waiting backend off the system() call in the first place? I suppose that if we can hack things so system() doesn't block SIGQUIT on Windows, it might be OK, at least for the "-m immediate" case. I was hoping we could get Query Cancel to SIGINT a system()-invoked script in a regular backend, but that might be too much to hope for on Windows, especially if it hasn't even got a distinction between INT and QUIT ... regards, tom lane
В списке pgsql-hackers по дате отправления: