Обсуждение: Failed assertion on cluster

I get the following:

$ TRAP: FailedAssertion("!(!(tup->t_data->t_infomask & 0x0010))", File: "heapam.c", Line: 1133)


when I try to cluster this table:

CREATE TABLE virtusers (    lhs text,    rhs text,    insert_date timestamp(0) with time zone DEFAULT now(),
insert_whotext DEFAULT "current_user"(),    "comment" text
 
);
ALTER TABLE ONLY virtusers ALTER COLUMN lhs SET STATISTICS 100;

--
-- Name: vu_lhs_index; Type: INDEX; Schema: public; Owner: ler; Tablespace: 
--

CREATE UNIQUE INDEX vu_lhs_index ON virtusers USING btree (lhs);


ALTER INDEX public.vu_lhs_index OWNER TO ler;


When I issue the cluster vu_lhs_index on virtusers, I get the 
above assertion.

8.0.1 on UnixWare 7.1.4


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Sun, 6 Feb 2005, Larry Rosenman wrote:

> I get the following:
>
> $ TRAP: FailedAssertion("!(!(tup->t_data->t_infomask & 0x0010))", File: 
> "heapam.c", Line: 1133)
>
>
> when I try to cluster this table:
>
> CREATE TABLE virtusers (
>    lhs text,
>    rhs text,
>    insert_date timestamp(0) with time zone DEFAULT now(),
>    insert_who text DEFAULT "current_user"(),
>    "comment" text
> );
> ALTER TABLE ONLY virtusers ALTER COLUMN lhs SET STATISTICS 100;
>
> --
> -- Name: vu_lhs_index; Type: INDEX; Schema: public; Owner: ler; Tablespace: 
> --
>
> CREATE UNIQUE INDEX vu_lhs_index ON virtusers USING btree (lhs);
>
>
> ALTER INDEX public.vu_lhs_index OWNER TO ler;
>
>
> When I issue the cluster vu_lhs_index on virtusers, I get the above 
> assertion.
>
> 8.0.1 on UnixWare 7.1.4
>
>
>
I had done the following, which I think is what's doing it:

1) alter table virtusers (and all the others in that db) set without oids;
2) changed postgresql.conf's default_with_oids to false.

Based on my read, this case is what's causing the grief.


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Sun, 6 Feb 2005, Larry Rosenman wrote:

>
> 1) alter table virtusers (and all the others in that db) set without oids;
> 2) changed postgresql.conf's default_with_oids to false.
>
> Based on my read, this case is what's causing the grief.

To get me out of it:
pg_dump exim >exim.db
psql template1
alter database exim rename to exim_broken;
create database exim
\c exim
\i exim.db

and now I can cluster it :)

I still have the exim_broken files, and DB available if someone wants to look
at it.



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler@lerctr.org> writes:
> I had done the following, which I think is what's doing it:
> 1) alter table virtusers (and all the others in that db) set without oids;

Ah.  I was just about to complain that I couldn't reproduce it, but
with that it crashes:

regression=# CREATE TABLE virtusers ...
regression=# CREATE UNIQUE INDEX vu_lhs_index ON virtusers USING btree (lhs);
CREATE INDEX
regression=# insert into virtusers values ('z','q');
INSERT 617078 1
regression=# insert into virtusers values ('zz','qq');
INSERT 617081 1
regression=# cluster vu_lhs_index on virtusers;
CLUSTER
-- [ reads next message ]
regression=# alter table virtusers  set without oids;
ALTER TABLE
regression=# cluster vu_lhs_index on virtusers;
server closed the connection unexpectedly

That ALTER doesn't change the on-disk contents immediately, it just
changes the catalogs; so the on-disk tuples are really illegal per the
new table definition, we're just lazy about updating them.  But CLUSTER
tries to re-store the rows without doing anything to them, and that
triggers this Assert.

Evidently it's not sufficient for copy_heap_data() to just copy the
tuples; it ought to build a fresh tuple with the same data, rather like
ALTER TABLE's rewriting code path does.  This would have the advantage
of, for example, collapsing dropped columns to NULLs immediately.

As a short term workaround, doing a rewriting ALTER gets the table back
into a clusterable state:

regression=# alter table virtusers alter column rhs type text;
ALTER TABLE
regression=# cluster vu_lhs_index on virtusers;
CLUSTER
regression=#
        regards, tom lane