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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster