Re: catalog corruption bug - Mailing list pgsql-hackers

From Jeremy Drake
Subject Re: catalog corruption bug
Date
Msg-id Pine.LNX.4.63.0601060834480.15097@garibaldi.apptechsys.com
Whole thread Raw
In response to Re: catalog corruption bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: catalog corruption bug
List 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 by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: could not access status of transaction 0
Next
From: Tom Lane
Date:
Subject: Re: catalog corruption bug