Magnus Hagander wrote:
> On Tue, Feb 1, 2011 at 02:25, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> I just tried doing pg_upgrade on a database when logged in as user
> >> "mha" rather than "postgres" on my system. And it failed. Even though
> >> the db was initialized with superuser "mha"
On Tue, Feb 1, 2011 at 02:25, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> I just tried doing pg_upgrade on a database when logged in as user
>> "mha" rather than "postgres" on my system. And it failed. Even though
>> the db was initialized with superuser "mha". The reason for this was
>> that
Magnus Hagander wrote:
> I just tried doing pg_upgrade on a database when logged in as user
> "mha" rather than "postgres" on my system. And it failed. Even though
> the db was initialized with superuser "mha". The reason for this was
> that pg_upgrade tried to connect to the database "mha" (hardco
Bernd Helmle writes:
> --On 28. Januar 2011 14:49:21 -0800 Josh Berkus wrote:
>> The database "postgres" is
>> reasonably likely to be dropped, whereas template1 doesn't get touched
>> usually.
> This is true for a bunch of installations i know. Maybe it's worth to make
> it a command line swit
--On 28. Januar 2011 14:49:21 -0800 Josh Berkus wrote:
The database "postgres" is
reasonably likely to be dropped, whereas template1 doesn't get touched
usually.
This is true for a bunch of installations i know. Maybe it's worth to make
it a command line switch to override the default beha
Magnus Hagander wrote:
> I just tried doing pg_upgrade on a database when logged in as user
> "mha" rather than "postgres" on my system. And it failed. Even though
> the db was initialized with superuser "mha". The reason for this was
> that pg_upgrade tried to connect to the database "mha" (hardco
> When that was fixed, I realized the psql command to create the
> datanbases connect to database "template1" only to immediately switch
> to database "postgres", which also seems rather pointless.
>
> Attach patch makes it connect to the "postgres" database instead of
> $USER, and then also chan
I just tried doing pg_upgrade on a database when logged in as user
"mha" rather than "postgres" on my system. And it failed. Even though
the db was initialized with superuser "mha". The reason for this was
that pg_upgrade tried to connect to the database "mha" (hardcoded to
be the db username), and
