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