Re: catalog corruption bug

From: Jeremy Drake <pgsql(at)jdrake(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: catalog corruption bug
Date: 2006-01-06 16:45:17
Message-ID: Pine.LNX.4.63.0601060834480.15097@garibaldi.apptechsys.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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?).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-01-06 16:59:31 Re: catalog corruption bug
Previous Message Stefan Kaltenbrunner 2006-01-06 16:28:34 Re: could not access status of transaction 0