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?).
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 |