> > 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
START_/END_CRIT_SECTION is mostly CritSectionCount++/--.
Recording could be made as LockedSpinLocks[LockedSpinCounter++] = &spinlock
in pre-allocated array.
Another way of implementing Transaction Abort + Exit could be some flag
in shmem setted by postmaster + QueryCancel..?
> sure this'd be enough anyway. Guaranteeing that you have consistent
> state at every instant that an ISR could interrupt you is not easy.
Agreed, but we have to forget old happy days when it was so easy to
shutdown DB. If we aren't able to release spins (eg excl buffer lock)
on Abort+Exit then instead of fast shutdown by pg_ctl -m fast stop
ppl can get checkpointer stuck attempting shlock that buffer.
(BTW, it's bad that pg_ctl doesn't wait on shutdown by default).
Vadim
