Use pg_repack for upgrading PKs from int4 to int8 - take 2

[David Boden]

Suggesting a different approach to getting new columns full of data, previously discussed in #197

I understand that the column metadata before and after the repack need to the the same. Would it be possible to carry out a multi-step process but use pg_repack in the middle to do the heavy lifting?

• Alter your table and add another nullable column with the target datatype.
• Create a "before insert" trigger which copies data from column_a into column_b whenever new tuples get added.
• Run pg_repack in such a way that it uses the trigger to generate values for column_b for all historical rows.
• Alter the table to set column_b to be NOT NULL.
• Drop column_a and rename column_b to column_a.

Sorry if this has already been considered or can't work with pg_repack. I've manually done these steps many times myself, but have to run a slow, batched update to give column_b all the right data. Then I have to repack the table at the end to get rid of all the dead tuples...

[Andreas Scherbaum]

This is outside the scope of pg_repack. This would transform pg_repack into a full migration tool.

Another tool which can do this can include pg_repack in the process, but pg_repack itself should not be extended to do this.

[Josef Šimánek]

I was thinking about another concept @andreasscherbaum to specify new target table manually (instead of creating it automatically as happening now). That way, in theory, some migrations could be done easily if schema would be compatible. Would patch be welcomed to open discussion?

[Andreas Scherbaum]

pg_repack still has to deal with checking all the compatibilities. Plenty of code needs to be changed to not create the destination table, but verify that it is there. Also requires quite a few test cases to make sure all of this is working.

While I see that such a feature can be helpful for certain migration cases, it's still way outside of the pg_repack scope.

[Josef Šimánek]

@andreasscherbaum my idea was to move this responsibility to user side, make this option experimental and print huge warning explaining anything can go wrong if schema is not compatible and it is up to user to check the compatibility. That could be IMHO enough for first iteration. It could be enhanced later with automated compatibility schema check and experimental flag with warning could be removed.

[Michael Vitale]

I would agree that stuff like this is way outside the scope of maintaining this vacuuming tool.

[Josef Šimánek]

I would agree that stuff like this is way outside the scope of maintaining this vacuuming tool.

IMHO pg_repack is currently far away from being just "vacuuming tool". But ok, message clear. Thanks for the info.