From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bug: Unreferenced temp tables disables vacuum to update xid |
Date: | 2008-01-14 23:38:02 |
Message-ID: | 20080114233802.GB31680@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2008-01-14 23:41:30 | Re: Declarative partitioning grammar |
Previous Message | Tom Lane | 2008-01-14 23:16:08 | Re: Bug: Unreferenced temp tables disables vacuum to update xid |