From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bob Ippolito <bob(at)redivi(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL 8.1.0 catalog corruption |
Date: | 2005-11-22 00:18:33 |
Message-ID: | 6136.1132618713@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bob Ippolito <bob(at)redivi(dot)com> writes:
> On Nov 21, 2005, at 3:56 PM, Tom Lane wrote:
>> Well, I count at least a couple hundred deleted versions of that table
>> row :-(. What the heck were you doing with it?
> The ETL process keeps trying until it succeeds or someone stops it,
> so I guess that's why there's so much churn in there for that table.
> Kept trying to create it, and ran into the issue. I'd estimate
> around 1700 to 1800 dead versions of that table, because it ran for
> some time before I noticed and stopped it... this is just a test box
> after all, I don't have 8.1 in production yet (thankfully!).
Um, no, that theory doesn't seem to explain the evidence. A failed
insertion would result in a row with an uncommitted XMIN and no XMAX.
All of the entries I'm seeing have both XMIN and XMAX set. A good-size
fraction have the same XMIN and XMAX (but different CMIN and CMAX), but
I see some that have different XMIN and XMAX. It looks to me like the
table was definitely created successfully, and it survived across
multiple transactions ... but something was doing a lot of DDL changes
on it. If we could find out what, maybe we could reproduce the problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2005-11-22 00:28:52 | Re: why is gist index taking so much space on the disc |
Previous Message | Bob Ippolito | 2005-11-22 00:08:54 | Re: PostgreSQL 8.1.0 catalog corruption |