Feedback-ID: id4a34324:Fastmail
Date: Thu, 09 Nov 2023 15:12:50 -0800
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>,
 "Kumar, Sachin" <ssetiya@amazon.com>
CC: Jacob Champion <champion.p@gmail.com>,
 Nathan Bossart <nathandbossart@gmail.com>, Jan Wieck <jan@wi3ck.info>,
 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>
Subject: Re: pg_upgrade failing for 200+ million Large Objects
User-Agent: K-9 Mail for Android
In-Reply-To: <1152134.1699555261@sss.pgh.pa.us>
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> <CAAWbhmgUb8p7ff_ZX5jCvqM=ipPxbbDJTXMNVzH-Ho_CXVkRHA@mail.gmail.com> <0643CC11-223A-4039-AC34-94E127462796@amazon.com> <1152134.1699555261@sss.pgh.pa.us>
Message-ID: <A975B443-F7D3-45BB-925B-FF1CF649DB54@anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/A975B443-F7D3-45BB-925B-FF1CF649DB54%40anarazel.de>
Precedence: bulk

Hi,=20

On November 9, 2023 10:41:01 AM PST, Tom Lane <tgl@sss=2Epgh=2Epa=2Eus> wr=
ote:
>Also, pg_upgrade is often invoked indirectly via scripts, so I do
>not especially buy the idea that we're going to get useful control
>input from some human somewhere=2E  I think we'd be better off to
>assume that pg_upgrade is on its own to manage the process, so that
>if we need to switch strategies based on object count or whatever,
>we should put in a heuristic to choose the strategy automatically=2E
>It might not be perfect, but that will give better results for the
>pretty large fraction of users who are not going to mess with
>weird little switches=2E

+1 - even leaving everything else aside, just about no user would know abo=
ut the option=2E There are cases where we can't do better than giving the u=
ser control, but we are certainly adding options at a rate that doesn't see=
m sustainable=2E And here it doesn't seem that hard to do better=2E=20

Andres=20
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E