> >> 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

Mon, 8 Jan 2001 22:58:11 -0800 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Quite strange crash 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>>>>> Killing an individual backend with SIGTERM is bad luck.  

> SIGTERM --> die() --> elog(FATAL)

> Is it true that elog(FATAL) doesn't clean up shmem etc?
> This would be very bad...

It tries, but I don't think it's possible to make a complete guarantee
without an unreasonable amount of overhead.  The case at hand was a
stuck spinlock because die() --> elog(FATAL) had neglected to release
that particular spinlock before exiting.  To guarantee that all
spinlocks will be released by die(), we'd need something like

	START_CRIT_SECTION;
	S_LOCK(spinlock);
	record that we own spinlock;
	END_CRIT_SECTION;

around every existing S_LOCK() call, and the reverse around every
S_UNLOCK.  Are you willing to pay that kind of overhead?  I'm not
sure this'd be enough anyway.  Guaranteeing that you have consistent
state at every instant that an ISR could interrupt you is not easy.

			regards, tom lane

Tue, 09 Jan 2001 02:12:57 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Quite strange crash 
* Mikheev, Vadim <vmikheev@SECTORBASE.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@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

Mon, 8 Jan 2001 23:23:43 -0800
Alfred Perlstein <bright@wintelcom.net>
Re: Quite strange crash
> > 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?

Sorry, I've meant "transaction abort"...

Vadim



Tue, 9 Jan 2001 00:34:52 -0800
"Vadim Mikheev" <vmikheev@sectorbase.com>
Re: Quite strange crash