Re: catalog corruption bug

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: catalog corruption bug
Дата
Msg-id 6616.1136831306@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: catalog corruption bug  (Jeremy Drake <pgsql@jdrake.com>)
Ответы Re: catalog corruption bug  (Jeremy Drake <pgsql@jdrake.com>)
Список pgsql-hackers
Jeremy Drake <pgsql@jdrake.com> writes:
> I ran without that function you made, and it got the error, but not a
> crash.  I stuck an Assert(false) right before the ereport for that
> particular error, and I did end up with a core there, but I don't see
> anything out of the ordinary (what little I know of the ordinary ;)

Yeah, that's just the CREATE TEMP TABLE doing what it's supposed to do.
The problem is presumably that a prior DROP operation failed to remove
the pg_type row associated with a previous temp table of the same name
... but why that would happen is still really unclear.

Does your application drop these temp tables explicitly, or leave them
to be dropped automatically during commit?  It might be interesting to
see whether changing that makes any difference.  I'm also curious
whether the transaction that makes the temp table is ever rolled back
instead of committed.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] plpgsql: check domain constraints
Следующее
От: Thomas Hallgren
Дата:
Сообщение: Re: PLs and domain constraints