Parts of this discussion are very much related to https://commitfest.postgresql.org/patch/5774/ - "Extending skipping FK checks on replicas to include ADD FK and TRUNCATE"
I have seen cases where adding a foreign key after copying data takes several days for no benefit at all. We should be allowing more of "skip unuseful work" options for all the cases we can be pretty sure the dat ais ok - upgrades, replica setups and restoring backup. We probably should also have an option to tolerate slight corruption, like duplicate PK entries if the source is an existing database. 99 times out of 100 the user would rather have a slight corruption than no database at all, for example in case they had to do an emergency restore and if fails after running 3 hours because ADD PRIMARY KEY hits a duplicate row. On Fri, Feb 6, 2026 at 8:40 PM Nathan Bossart <[email protected]> wrote: > > On Thu, Feb 05, 2026 at 03:29:55PM -0600, Nathan Bossart wrote: > > Here is what I have so far. > > BTW I ran 006_transfer_modes.pl (which tests LOs with comments and security > labels) for upgrades from v10, v13, v16, v17, and v18, and all tests > succeeded. > > -- > nathan
