Horton

Thread

  1. Fix for pg_upgrade user flag

    Bruce Momjian <bruce@momjian.us> — 2011-05-07T12:56:10Z

    The attached, applied patch checks that the pg_upgrade user specified is
a super-user.  It also reports the error message when the post-pg_ctl
connection fails.

This was prompted by a private bug report from EnterpriseDB.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  2. Re: Fix for pg_upgrade user flag

    Robert Haas <robertmhaas@gmail.com> — 2011-05-07T13:50:40Z

    On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <bruce@momjian.us> wrote:
> The attached, applied patch checks that the pg_upgrade user specified is
> a super-user.  It also reports the error message when the post-pg_ctl
> connection fails.
>
> This was prompted by a private bug report from EnterpriseDB.

It strikes me that it's fairly crazy to think you're going to be able
to catch all the possible errors the server might throw this way.
Don't we need some way of letting the actual server errors leak out?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

  3. Re: Fix for pg_upgrade user flag

    Robert Haas <robertmhaas@gmail.com> — 2011-05-07T13:55:35Z

    On Sat, May 7, 2011 at 9:50 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> The attached, applied patch checks that the pg_upgrade user specified is
>> a super-user.  It also reports the error message when the post-pg_ctl
>> connection fails.
>>
>> This was prompted by a private bug report from EnterpriseDB.
>
> It strikes me that it's fairly crazy to think you're going to be able
> to catch all the possible errors the server might throw this way.
> Don't we need some way of letting the actual server errors leak out?

Or, hmm.  Maybe you just did that.  If so, never mind.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

  4. Re: Fix for pg_upgrade user flag

    Bruce Momjian <bruce@momjian.us> — 2011-05-07T16:21:12Z

    Robert Haas wrote:
> On Sat, May 7, 2011 at 9:50 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <bruce@momjian.us> wrote:
> >> The attached, applied patch checks that the pg_upgrade user specified is
> >> a super-user. ?It also reports the error message when the post-pg_ctl
> >> connection fails.
> >>
> >> This was prompted by a private bug report from EnterpriseDB.
> >
> > It strikes me that it's fairly crazy to think you're going to be able
> > to catch all the possible errors the server might throw this way.
> > Don't we need some way of letting the actual server errors leak out?
> 
> Or, hmm.  Maybe you just did that.  If so, never mind.  :-)

What I did was to report the errors of our first database probe after we
started the server --- for some reason, that code was not reporting the
libpq error message, while all other failed connections did.

The second change was to only run pg_upgrade as a database super-user,
and hopefully that will avoid odd pg_dump error messages.  

One question I have is why we even bother to allow the database username
to be specified?  Shouldn't we just hard-code that to 'postgres'?  Is
there any reason to allow another username to be used?  You can't drop
the postgres user but you can remove super-user permissions from it so
maybe we have to continue allowing it:

	postgres=> drop user postgres;
	ERROR:  cannot drop role postgres because it is required by the database system
	postgres=> alter user postgres nosuperuser;
	ALTER ROLE

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  5. Re: Fix for pg_upgrade user flag

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-07T17:43:21Z

    Bruce Momjian <bruce@momjian.us> writes:
> One question I have is why we even bother to allow the database username
> to be specified?  Shouldn't we just hard-code that to 'postgres'?

Only if you want to render pg_upgrade unusable by a significant fraction
of people.  "postgres" is not the hard wired name of the bootstrap
superuser.

			regards, tom lane

  6. Re: Fix for pg_upgrade user flag

    Bruce Momjian <bruce@momjian.us> — 2011-05-07T17:50:48Z

    Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > One question I have is why we even bother to allow the database username
> > to be specified?  Shouldn't we just hard-code that to 'postgres'?
> 
> Only if you want to render pg_upgrade unusable by a significant fraction
> of people.  "postgres" is not the hard wired name of the bootstrap
> superuser.

I was really wondering if I should be using that hard-coded name, rather
than allowing the user to supply it.  They have to compile in a
different name, and I assume that name is accessible somewhere.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  7. Re: Fix for pg_upgrade user flag

    Peter Eisentraut <peter_e@gmx.net> — 2011-05-07T20:48:14Z

    On lör, 2011-05-07 at 13:50 -0400, Bruce Momjian wrote:
> I was really wondering if I should be using that hard-coded name,
> rather than allowing the user to supply it.  They have to compile in a
> different name, and I assume that name is accessible somewhere.

"postgres" is not compiled in.  It's whatever user you run initdb under.
In particular, in the regression tests, it is probably not "postgres".

  8. Re: Fix for pg_upgrade user flag

    Bruce Momjian <bruce@momjian.us> — 2011-05-07T22:48:49Z

    Peter Eisentraut wrote:
> On l?r, 2011-05-07 at 13:50 -0400, Bruce Momjian wrote:
> > I was really wondering if I should be using that hard-coded name,
> > rather than allowing the user to supply it.  They have to compile in a
> > different name, and I assume that name is accessible somewhere.
> 
> "postgres" is not compiled in.  It's whatever user you run initdb under.
> In particular, in the regression tests, it is probably not "postgres".

Thanks.  I get confused because the 'postgres' database is hardcoded in,
but not the username.  Not sure why I am so easily confused.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  9. Re: Fix for pg_upgrade user flag

    Andrew Dunstan <andrew@dunslane.net> — 2011-05-07T23:03:16Z

    
On 05/07/2011 06:48 PM, Bruce Momjian wrote:
>> "postgres" is not compiled in.  It's whatever user you run initdb under.
>> In particular, in the regression tests, it is probably not "postgres".
> Thanks.  I get confused because the 'postgres' database is hardcoded in,
> but not the username.  Not sure why I am so easily confused.


There is a requirement for a known database name, but no requirement for 
a known superuser name.

cheers

andrew