Re: [GENERAL] pg_upgrade -u - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [GENERAL] pg_upgrade -u
Date
Msg-id 20130529025520.GA12969@momjian.us
Whole thread Raw
Responses Re: [GENERAL] pg_upgrade -u
Re: [GENERAL] pg_upgrade -u
Re: [GENERAL] pg_upgrade -u
List pgsql-hackers
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  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Attachment

pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Next
From: Alvaro Herrera
Date:
Subject: Re: Planning incompatibilities for Postgres 10.0