On Wed, May 22, 2013 at 03:05:57PM -0400, Ray Stell wrote:
> > However, if we pass these items into the scripts, we then force
> > these values to be used, even if the user wants to use a different
> > value. It is a balance between supplying defaults vs. requiring the
> > user to supply or change the values used during the ugprade.
> >
> > At this point, I have favored _not_ supplying defaults in the
> > script. Do you have an alternative argument in favor of supplying
> > defaults?
>
>
>
> Well, the story really began when I ran initdb with a -U arg. vacuumdb
> takes the -U also, but pg_upgrade does not.
>
> It seems like if I have to supply a -u in order to get pg_upgrade
> to function in the case where there is no default superuser in the
> cluster, then an associated vacuumdb command requires a -U arg.
>
> Perhaps just documenting the behavior is all that is needed, but -U is
> everywhere and I think that's a good thing.
[ moved to hacker ]
Wow, I never realized other tools used -U for user, instead of -u.
Should I change pg_upgrade to use -U for 9.4? I can keep supporting -u
as an undocumented option.
I have applied the attached patch to document that you might need to set
connection parameters for vacuumdb.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
new file mode 100644
index d676d28..4ac0e56
*** a/doc/src/sgml/pgupgrade.sgml
--- b/doc/src/sgml/pgupgrade.sgml
*************** psql --username postgres --file script.s
*** 442,448 ****
<para>
Because optimizer statistics are not transferred by <command>pg_upgrade</>, you will
be instructed to run a command to regenerate that information at the end
! of the upgrade.
</para>
</step>
--- 442,449 ----
<para>
Because optimizer statistics are not transferred by <command>pg_upgrade</>, you will
be instructed to run a command to regenerate that information at the end
! of the upgrade. You might need to set connection parameters to
! match your new cluster.
</para>
</step>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
