Re: Upgrading using pg_dumpall - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Upgrading using pg_dumpall
Date
Msg-id 11bddea1-b933-048a-a3ef-dcdaf6e953ca@aklaver.com
Whole thread Raw
In response to Re: Upgrading using pg_dumpall  (Rich Shepard <rshepard@appl-ecosys.com>)
Responses Re: Upgrading using pg_dumpall  (Rich Shepard <rshepard@appl-ecosys.com>)
List pgsql-general
On 09/04/2016 12:10 PM, Rich Shepard wrote:
> On Sun, 4 Sep 2016, Adrian Klaver wrote:
>
>> You don't it directly. That information is supplied by Postgres when you
>> do CREATE or ALTER ROLE. The -W switch just does that for the
>> superuser(postgres in your case) when you initdb a new cluster.
>
> Adrian,
>
>   OK. That makes sense.
>
>> Sorry, old habits. pg_user is a version of the pg_shadow view that blanks
>> out the actual password. pg_shadow is a view over the table pg_authid,
>> where the actual information is stored now. In any case, again they are
>> not tables/views you directly modify.
>
>   Good. Then I won't spend time with them.
>
>   So, given my single-user situation do you think that I should ALTER ROLE
> to add my password? Adding it to ~/.pgpass did nothing positive when I
> changed auth method to md5; my attempt to open a database failed because
> that password was rejected. Strange ... to me.

Another thing that came to mind is compatibility with existing
applications/clients. You say you have been running using trust and I am
betting your client connection parameters reflect that. Now for
connections methods that can 'see' the .pgpass file and use libpq as the
their underlying Postgres library then things should work. Otherwise
your applications may not be able to connect until you supply the
correct password in some manner.

>
> Rich
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Rich Shepard
Date:
Subject: Re: Upgrading using pg_dumpall
Next
From: Adrian Klaver
Date:
Subject: Re: Upgrading using pg_dumpall