Re: Error exits (Re: [HACKERS] Open 6.5 items)

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Error exits (Re: [HACKERS] Open 6.5 items)
Date: 1999-06-03 17:59:20
Message-ID: 3756C278.5A16DB4B@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> Vadim Mikheev <vadim(at)krs(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-06-03 18:09:13 Re: [HACKERS] Re: Freezing docs for v6.5
Previous Message Tom Lane 1999-06-03 17:53:22 Error exits (Re: [HACKERS] Open 6.5 items)