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
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