Обсуждение: 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