Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible

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 <nathandbossart@gmail.com> 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