From: | Alfred Perlstein <bright(at)wintelcom(dot)net> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Denis Perchine <dyp(at)perchine(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Quite strange crash |
Date: | 2001-01-09 07:23:43 |
Message-ID: | 20010108232342.M15744@fw.wintelcom.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Mikheev, Vadim <vmikheev(at)SECTORBASE(dot)COM> [010108 23:08] wrote:
> > >> 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?
Er, shouldn't ABORT leave the system in the exact state that it's
in so that one can get a crashdump/traceback on a wedged process
without it trying to clean up after itself?
--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 2001-01-09 08:34:52 | Re: Quite strange crash |
Previous Message | Tom Lane | 2001-01-09 07:12:57 | Re: Quite strange crash |