Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling
Дата
Msg-id 6299.1502209596@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 8, 2017 at 11:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We could respond to this by using PG_ENSURE_ERROR_CLEANUP there instead
>> of plain PG_TRY.  But I have an itchy feeling that there may be a lot
>> of places with similar issues.  Should we be revisiting the basic way
>> that elog(FATAL) works, to make it less unlike elog(ERROR)?

> ... Arguably, this assertion is merely overzealous; we could skip
> this processing when proc_exit_inprogress, for example.

Yeah, I thought about weakening the assertions too, but I couldn't
see a fix of that kind that didn't seem mighty ad-hoc.

Now, there is some room to argue that AtEOXact_CatCache() is just
obsolete and we should remove it altogether; I don't think it's
caught a real bug since we invented resowners in 8.1.  Short of that,
though, I'm not really happy with just arbitrarily weakening the
checks.

But, again, the larger question to my mind is where else we may have
similar issues.  There's certainly never been any methodical attempt
to see whether elog(FATAL) will work everywhere.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sandeep Thakkar
Дата:
Сообщение: Re: [HACKERS] pl/perl extension fails on Windows
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling