Hello dear -hackers, I'm maintaining pg_reorg/pg_repack, which you may know effectively allow online VACUUM FULL or CLUSTER. It works by installing logging triggers to keep data up-to-date during the migration, creating a copy of the table, and eventually swapping the tables relfilenodes.
The new table is forced to keep exactly the same physical structure, e.g. restoring dropped columns too. Failing to do so was apparently a big mistake, looking at this commit [1]. My knowledge of Postgres at that level is limited: what I imagine is that cached plans keep the offset of the field in the row, so data ends up read/written in the wrong position if such offset changes. The commit message mentions views and stored procedures being affected. Is there a way to force invalidation of all the cache that may hold a reference to the columns offset? Or is the problem an entirely different one and the above cache invalidation wouldn't be enough? If we managed to allow schema change in pg_repack we could allow many more online manipulations features: changing data types, reordering columns, really dropping columns freeing up space etc. Thank you very much, -- Daniele [1] https://github.com/reorg/pg_repack/commit/960930b645df8eeeda15f176c95d3e450786f78a -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
