Re: [GENERAL] Shutting down a warm standby database in 8.2beta3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Shutting down a warm standby database in 8.2beta3
Date
Msg-id 7456.1164040831@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Shutting down a warm standby database in 8.2beta3  ("Magnus Hagander" <mha@sollentuna.net>)
List 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 by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: [GENERAL] Shutting down a warm standby database in 8.2beta3
Next
From: "Simon Riggs"
Date:
Subject: Re: [PATCHES] Transaction start in pg_stat_activity