Tom Lane wrote: > regression=# cluster foo_pkey on foo; > CLUSTER > regression=# select relname, relkind, relfrozenxid from pg_class order by oid > desc limit 6; > relname | relkind | relfrozenxid > -----------------------+---------+-------------- > pg_toast_707231_index | i | 0 > pg_toast_707231 | t | 119424 > foo_pkey | i | 0 > foo | r | 4195086720 > foo_f1_seq | S | 0 > xmlview5 | v | 0 > (6 rows) > > So something is out of whack in CLUSTER. However it only seems to be > broken in HEAD, so I'm not sure this helps to explain the original > report. (Speculation: this is related to the rewrite to make CLUSTER > MVCC-safe?)
Right ... see copy_heap_data --- it sets FreezeXid as relfrozenxid. If we were to scan each tuple as it is inserted, we could store a higher relfrozenxid, but I doubt we want to do that. Perhaps what we could do is take the relfrozenxid from the old relation and copy it over, if it's later than FreezeXid? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
