* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > Having to also deal with shared_preload_libraries for some cases doesn't > > strike me as a huge issue. > > I think it is, especially if what we're offering as a workaround is "write > a custom script and make sure that your pg_upgrade wrapper script has an > option to call that halfway through". Rube Goldberg would be proud. > > It's possible that the problem here is not so much reliance on > shared_preload_libraries as it is that there's no provision in > pg_upgrade for dealing with the need to set it. But one way or > the other, this is a usability fail.
Why would it be pg_upgrade? When using it, you initdb the new cluster
yourself and you can configure the postgresql.conf in there however you
like before running the actual pg_upgrade. Sure, if you're using a
wrapper then you need to deal with that, but if you want pg_upgrade to
handle configuration options in postgresql.conf then you're going to
have to pass config info to the wrapper script anyway, which would then
pass it to pg_upgrade.
The wrapper script may even already deal with this if it copies the old
postgresql.conf into place (which I think the Debian one might do, with
a bit of processing for anything that needs to be addressed between the
major versions.. not looking at it right now though).
More generally, I completely agree that this is something which we can
improve upon. It doesn't seem like a release blocker or something which
we need to fix in the back branches though.
Thanks,
Stephen
signature.asc
Description: Digital signature
