MIME-Version: 1.0
References: <c0f5fde5-5cad-65ed-dd30-cd852301d074@wi3ck.info>
 <986904.1616525964@sss.pgh.pa.us>
 <6cccaa33-c263-b8a2-b064-985605d33d25@wi3ck.info>
 <988415.1616528159@sss.pgh.pa.us>
 <872315a8-99fc-da4e-463d-784cfb5a025d@wi3ck.info>
 <1010642.1616532950@sss.pgh.pa.us>
 <802b96e9-f5e1-015c-dfb9-8756974b11fc@wi3ck.info>
 <0263bf35-05d6-02a1-519b-b7895a918314@wi3ck.info>
 <20220825003227.GA1456581@nathanxps13>
 <663393ca-b2ff-26f0-2e2d-adc942aff4fd@timescale.com>
 <20220908231807.GA2242918@nathanxps13>
In-Reply-To: <20220908231807.GA2242918@nathanxps13>
From: Jacob Champion <jchampion@timescale.com>
Date: Thu, 8 Sep 2022 16:29:10 -0700
Message-ID: 
 <CAAWbhmgUb8p7ff_ZX5jCvqM=ipPxbbDJTXMNVzH-Ho_CXVkRHA@mail.gmail.com>
Subject: Re: pg_upgrade failing for 200+ million Large Objects
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Jan Wieck <jan@wi3ck.info>, Tom Lane <tgl@sss.pgh.pa.us>,
 Bruce Momjian <bruce@momjian.us>,
	Zhihong Yu <zyu@yugabyte.com>, Andrew Dunstan <andrew@dunslane.net>,
	Magnus Hagander <magnus@hagander.net>, Robins Tharakan <tharakan@gmail.com>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAWbhmgUb8p7ff_ZX5jCvqM%3DipPxbbDJTXMNVzH-Ho_CXVkRHA%40mail.gmail.com>
Precedence: bulk

On Thu, Sep 8, 2022 at 4:18 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> IIUC the main benefit of this approach is that it isn't dependent on
> binary-upgrade mode, which seems to be a goal based on the discussion
> upthread [0].

To clarify, I agree that pg_dump should contain the core fix. What I'm
questioning is the addition of --dump-options to make use of that fix
from pg_upgrade, since it also lets the user do "exciting" new things
like --exclude-schema and --include-foreign-data and so on. I don't
think we should let them do that without a good reason.

Thanks,
--Jacob