Failed assertion on cluster

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