Re: Error exits (Re: [HACKERS] Open 6.5 items) - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: Error exits (Re: [HACKERS] Open 6.5 items)
Date
Msg-id 3756C278.5A16DB4B@krs.ru
Whole thread Raw
In response to Error exits (Re: [HACKERS] Open 6.5 items)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 
> Vadim Mikheev <vadim@krs.ru> writes:
> >> It seems elog(FATAL) doesn't release allocated buffer pages.
> >> It's OK ?
> >> AFAIC elog(FATAL) causes proc_exit(0) and proc_exit() doesn't
> >> call ResetBufferPool().
> 
> > Seems to me that elog(FATAL) should call siglongjmp(Warn_restart, 1),
> > like elog(ERROR), but force exit in tcop main loop after
> > AbortCurrentTransaction(). AbortTransaction() does pretty nice
> > things like RelationPurgeLocalRelation(false) and DestroyNoNameRels()...
> 
> Seems reasonable to me.  It seems to me that elog(FATAL) means "this
> backend is too messed up to continue, but I think the rest of the
> backends can keep going."  So we need to clean up our allocated
> resources before quitting.  abort() is for the cases where we think
> shared memory may be corrupted and everyone must bail out.  We might
> need to revisit the uses of each routine and make sure that different
> error conditions are properly classified.
> 
> Of course, if things *are* messed up then trying to AbortTransaction
> might make it worse.  How bad is that risk?

Don't know. I think that we have no time to fix this in 6.5, -:(

Vadim


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Error exits (Re: [HACKERS] Open 6.5 items)
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: Freezing docs for v6.5