Re: [HACKERS] Ack...major(?) bug just found in v6.3.1...

From: dg(at)illustra(dot)com (David Gould)
To: vadim(at)sable(dot)krasnoyarsk(dot)su (Vadim B(dot) Mikheev)
Cc: scrappy(at)hub(dot)org, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Ack...major(?) bug just found in v6.3.1...
Date: 1998-04-07 02:53:13
Message-ID: 9804070253.AA17366@hawk.illustra.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> The Hermit Hacker wrote:
> >
> > acctng=> vacuum radlog;
> > NOTICE: BlowawayRelationBuffers(radlog, 3): block 786 is referenced
> > (private 0, last 0, global 53)
> ^^^^^^^^^
> I assume that you got some FATAL before vacuum.
>
> We have problems with elog(FATAL): backend just exits (with normal code)
> and postmaster doesn't re-initialize shmem etc though backend could
> have some spinlocks and pinned buffers. This leaves system in unpredictable
> state!
>
> IMO, in elog(FATAL) backend should abort() (just like in ASSERT).

The other way to do this, and it might be a good idea is to review the code
for elogs while holding a spinlock and make sure to release the lock first!

This problem will get worse if we start allowing query cancelation from
the client, and when the spinlock backoff code goes in.

In the long run you have to make all the signal handlers safe. Safe means
they set a flag and the code periodically polls for it to catch whatever
the condition is. Obviously this doesn't work for SEGV etc, but IO and the
timers yes.

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- Linux. Not because it is free. Because it is better.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 1998-04-07 06:00:02 Re: [HACKERS] Developer setup, what works?
Previous Message Vadim B. Mikheev 1998-04-07 01:39:02 Re: [HACKERS] Ack...major(?) bug just found in v6.3.1...