Thread: Should shared_preload_libraries be loaded during binary upgrade?

Does it make sense to load "shared_preload_libraries" during binary
upgrade mode?

An extension might unintentionally interfere with pg_upgrade, for
example, by connecting to the 'postgres' database, which can cause the
upgrade to fail as the restore needs to drop that database. While it's
true that extensions should ideally handle this themselves, wouldn't
it be safer if we could avoid loading them at all during the binary
upgrade mode?

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



On Thu, May  1, 2025 at 11:05:56AM +0530, Dilip Kumar wrote:
> Does it make sense to load "shared_preload_libraries" during binary
> upgrade mode?
> 
> An extension might unintentionally interfere with pg_upgrade, for
> example, by connecting to the 'postgres' database, which can cause the
> upgrade to fail as the restore needs to drop that database. While it's
> true that extensions should ideally handle this themselves, wouldn't
> it be safer if we could avoid loading them at all during the binary
> upgrade mode?

Well, the library might be required to load the data.  Why would we
avoid it with no known error reports?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.



Bruce Momjian <bruce@momjian.us> writes:
> On Thu, May  1, 2025 at 11:05:56AM +0530, Dilip Kumar wrote:
>> Does it make sense to load "shared_preload_libraries" during binary
>> upgrade mode?

> Well, the library might be required to load the data.  Why would we
> avoid it with no known error reports?

You could invent examples that would break things in either direction.
I'm inclined to leave it alone, because right now the choice is under
the user's control: she can adjust shared_preload_libraries if needed
in either the source or target clusters.  If we try to force the
matter, then one set of problem cases is broken without recourse.

The lack of field problem reports is another good reason for not
touching this.

            regards, tom lane



On Thu, May 01, 2025 at 10:05:48AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> On Thu, May  1, 2025 at 11:05:56AM +0530, Dilip Kumar wrote:
>>> Does it make sense to load "shared_preload_libraries" during binary
>>> upgrade mode?
> 
>> Well, the library might be required to load the data.  Why would we
>> avoid it with no known error reports?
> 
> You could invent examples that would break things in either direction.
> I'm inclined to leave it alone, because right now the choice is under
> the user's control: she can adjust shared_preload_libraries if needed
> in either the source or target clusters.  If we try to force the
> matter, then one set of problem cases is broken without recourse.
> 
> The lack of field problem reports is another good reason for not
> touching this.

+1, I believe I've seen cases where loading the library was necessary and
others where it breaks the upgrade.  A one-size-fits-all approach probably
won't work here.

-- 
nathan



Re: Should shared_preload_libraries be loaded during binary upgrade?

From
Michael Paquier
Date:
On Thu, May 01, 2025 at 09:14:50AM -0500, Nathan Bossart wrote:
> +1, I believe I've seen cases where loading the library was necessary and
> others where it breaks the upgrade.  A one-size-fits-all approach probably
> won't work here.

Yes, it really depends on one's expections.

The area I known about that causes most of the problems depending on
what's loaded by shared_preload_libraries is background workers that
forget to do some check based on IsBinaryUpgrade when these are loaded
in a cluster running during an upgrade.  The most popular extension do
that (example: pg_cron), but perhaps this is mostly a documentation
issue and we ought to do a better job regarding that?

Other example: worker_spi.c does not include such a check, but it
creates tables, and I'm pretty sure that it's common for newcomers to
copy-paste such "template" code from the tree when implementing their
own extensions.
--
Michael

Attachment
On Thu, May 1, 2025 at 7:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Bruce Momjian <bruce@momjian.us> writes:
> > On Thu, May  1, 2025 at 11:05:56AM +0530, Dilip Kumar wrote:
> >> Does it make sense to load "shared_preload_libraries" during binary
> >> upgrade mode?
>
> > Well, the library might be required to load the data.  Why would we
> > avoid it with no known error reports?
>
> You could invent examples that would break things in either direction.
> I'm inclined to leave it alone, because right now the choice is under
> the user's control: she can adjust shared_preload_libraries if needed
> in either the source or target clusters.  If we try to force the
> matter, then one set of problem cases is broken without recourse.

Yeah, that makes sense, so let's leave it alone.  Thanks.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com