Tom Lane wrote: > Bob Ippolito <[EMAIL PROTECTED]> 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.
Maybe the UPDATE pg_class SET relhastriggers='f' that people is so fond of doing to deactivate triggers? Or something similar? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
