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.