From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Denis Perchine <dyp(at)perchine(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: Quite strange crash |
Date: | 2001-01-09 06:58:11 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D3243@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> >> Killing an individual backend with SIGTERM is bad luck.
> >> The backend will assume that it's being killed by the postmaster,
> >> and will exit without a whole lot of concern for cleaning up shared
> >> memory --- the
SIGTERM --> die() --> elog(FATAL)
Is it true that elog(FATAL) doesn't clean up shmem etc?
This would be very bad...
> > What code will be returned to postmaster in this case?
>
> Right at the moment, the backend will exit with status 0. I think you
> are thinking the same thing I am: maybe a backend that
> receives SIGTERM ought to exit with nonzero status.
>
> That would mean that killing an individual backend would instantly
> translate into an installation-wide restart. I am not sure whether
> that's a good idea. Perhaps this cure is worse than the disease.
Well, it's not good idea because of SIGTERM is used for ABORT + EXIT
(pg_ctl -m fast stop), but shouldn't ABORT clean up everything?
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-01-09 07:12:57 | Re: Quite strange crash |
Previous Message | Tom Lane | 2001-01-09 06:40:49 | Re: Quite strange crash |