Re: PostgreSQL 8.1.0 catalog corruption
От | Tom Lane |
---|---|
Тема | Re: PostgreSQL 8.1.0 catalog corruption |
Дата | |
Msg-id | 6136.1132618713@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PostgreSQL 8.1.0 catalog corruption (Bob Ippolito <bob@redivi.com>) |
Ответы |
Re: PostgreSQL 8.1.0 catalog corruption
|
Список | pgsql-hackers |
Bob Ippolito <bob@redivi.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
В списке pgsql-hackers по дате отправления: