Re: Fix for pg_upgrade user flag

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <bruce(at)momjian(dot)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

On Sat, May 7, 2011 at 9:50 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <bruce(at)momjian(dot)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

Robert Haas wrote:
> On Sat, May 7, 2011 at 9:50 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)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

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

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".

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

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