ALTER TABLE ... SET STORAGE does not propagate to indexes

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-01-06T12:32:53Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Propagate ALTER TABLE ... SET STORAGE to indexes

Attachments

ALTER TABLE ... SET STORAGE does not propagate to indexes, even though 
indexes created afterwards get the new storage setting.  So depending on 
the order of commands, you can get inconsistent storage settings between 
indexes and tables.  For example:

create table foo1 (a text);
alter table foo1 alter column a set storage external;
create index foo1i on foo1(a);
insert into foo1 values(repeat('a', 10000));
ERROR:  index row requires 10016 bytes, maximum size is 8191

(Storage "external" disables compression.)

but

create table foo1 (a text);
create index foo1i on foo1(a);
alter table foo1 alter column a set storage external;
insert into foo1 values(repeat('a', 10000));
-- no error

Also, this second state cannot be reproduced by pg_dump, so a possible 
effect is that such a database would fail to restore.

Attached is a patch that attempts to fix this by propagating the storage 
change to existing indexes.  This triggers a few regression test 
failures (going from no error to error), which I attempted to fix up, 
but I haven't analyzed what the tests were trying to do, so it might 
need another look.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services