Re: catalog corruption bug

Поиск
Список
Период
Сортировка
От Jeremy Drake
Тема Re: catalog corruption bug
Дата
Msg-id Pine.LNX.4.63.0601060834480.15097@garibaldi.apptechsys.com
обсуждение исходный текст
Ответ на Re: catalog corruption bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: catalog corruption bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, 5 Jan 2006, Tom Lane wrote:

> The ReadBuffer bug I just fixed could result in disappearance of catalog
> rows, so this observation is consistent with the theory that that's
> what's biting you.  It's not proof though...

Well, I applied that patch that you sent me the link to (the bufmgr.c
one), and rebuilt (PORTDIR_OVERLAY is cool...)

I ran my nine processes which hammer things overnight, and in the
morning one of them was dead.

DBD::Pg::st execute failed: ERROR:  duplicate key violates unique
constraint "pg_type_typname_nsp_index"
CONTEXT:  SQL statement "CREATE TEMPORARY TABLE push_tmp (val text) ON
COMMIT DROP"
PL/pgSQL function "push_func" line 6 at SQL statement
DBD::Pg::st execute failed: ERROR:  duplicate key violates unique
constraint "pg_type_typname_nsp_index"
CONTEXT:  SQL statement "CREATE TEMPORARY TABLE push_tmp (val text) ON
COMMIT DROP"
PL/pgSQL function "push_func" line 6 at SQL statement


I also write out the time as my processes progress, so I know roughly when
it happened too.  It happened at 1136534029 (that's result of perl time()
function), which when run through localtime() yields Thu Jan  5 23:53:49
2006.  It looks like I started the processes at about 18:30, so they
lasted a while at least.

Let me know if there is anything else I can try to help debug this
(asserts on?).


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

Предыдущее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: could not access status of transaction 0
Следующее
От: Tom Lane
Дата:
Сообщение: Re: catalog corruption bug