Re: Bug: Unreferenced temp tables disables vacuum to update xid

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.

In response to

Responses

Browse pgsql-hackers by date

  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