Re: Bug: Unreferenced temp tables disables vacuum to update xid - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug: Unreferenced temp tables disables vacuum to update xid
Date
Msg-id 8131.1200352568@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug: Unreferenced temp tables disables vacuum to update xid  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Bug: Unreferenced temp tables disables vacuum to update xid  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Hmm ... that would be strange.  Off-the-cuff idea: we introduced code to
> advance relfrozenxid in CLUSTER, TRUNCATE and table-rewriting forms of
> ALTER TABLE.  Perhaps the problem is that we're neglecting to update it
> for the toast table there. AFAIR I analyzed the cases and they were all
> handled, but perhaps I forgot something.

I found a smoking gun ...

regression=# create table foo (f1 serial primary key, f2 text);
NOTICE:  CREATE TABLE will create implicit sequence "foo_f1_seq" for serial column "foo.f1"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
CREATE TABLE
regression=# insert into foo values(1,repeat('xyzzy',100000));
INSERT 0 1
regression=# insert into foo values(2,repeat('xqzzy',100000));
INSERT 0 1
regression=# select relname, relkind, relfrozenxid from pg_class order by oid desc limit 6;       relname        |
relkind| relfrozenxid 
 
-----------------------+---------+--------------foo_pkey              | i       |            0pg_toast_707220_index | i
     |            0pg_toast_707220       | t       |       119421foo                   | r       |
119421foo_f1_seq           | S       |            0xmlview5              | v       |            0
 
(6 rows)

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       |            0pg_toast_707231       | t
     |       119424foo_pkey              | i       |            0foo                   | r       |
4195086720foo_f1_seq           | S       |            0xmlview5              | 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?)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: to_char incompatibility
Next
From: Gavin Sherry
Date:
Subject: Re: Declarative partitioning grammar