* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@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