On 09/04/2016 12:55 PM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
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
connection
On Sun, 4 Sep 2016, Adrian Klaver wrote:
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
On 09/04/2016 12:42 PM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Well first, if you are going to use trust as your auth method then
specifying a password is moot exercise.
I tried adding an explicit password to ~/.pgpass with md5 as the auth
method, but that didn't work
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,
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Well first, if you are going to use trust as your auth method then specifying
a password is moot exercise.
I tried adding an explicit password to ~/.pgpass with md5 as the auth
method, but that didn't work so I went back to trust. That's served well f
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,
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.
On 09/04/2016 09:43 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
-W is not referring to the OS user but the database superuser. Now in
your
case they have the same name, postgres. The settings in /etc/passwd are
not relevant to what -W is doing. -W is referring to user infor
On Sun, 4 Sep 2016, Adrian Klaver wrote:
I would take Charles's suggestion and set up a .pgpass file just to be
safe.
The file ~/.pgpass already exists, but without an explicit password. I
added my password (plain text). The file already had perms 0600. Perhaps my
password was rejected with
On Sun, 4 Sep 2016, Adrian Klaver wrote:
-W is not referring to the OS user but the database superuser. Now in your
case they have the same name, postgres. The settings in /etc/passwd are
not relevant to what -W is doing. -W is referring to user information
being stored in the cluster in the sys
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Just be aware that you now have a password for the postgres user and that
if you ever do enable md5 you will need it. I would take Charles's
suggestion and set up a .pgpass file just to be safe.
Adrian,
OK. I'll also read the page at the URL you provi
On 09/04/2016 09:01 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Actually there is an important difference. In your 9.3 file you have set
METHOD set to trust and in the 9.5 file it is set to md5, which is
password. Set the METHOD to trust in your 9.5 file and restart the
dat
On 09/04/2016 09:01 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Actually there is an important difference. In your 9.3 file you have set
METHOD set to trust and in the 9.5 file it is set to md5, which is
password. Set the METHOD to trust in your 9.5 file and restart the
dat
On Sun, 4 Sep 2016, Adrian Klaver wrote:
-W is not referring to the OS user but the database superuser. Now in your
case they have the same name, postgres. The settings in /etc/passwd are
not relevant to what -W is doing. -W is referring to user information
being stored in the cluster in the sys
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Well, there you have it. As Adrian suggested you may set temporarily the
authentication method to trust, set yourself a password and change it back
to md5.
Charles,
I've had a password on this LAN for almost 2 decades. I've not before set
a p
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Actually there is an important difference. In your 9.3 file you have set
METHOD set to trust and in the 9.5 file it is set to md5, which is
password. Set the METHOD to trust in your 9.5 file and restart the
database. Now for the non-socket access methods
On 09/04/2016 08:14 AM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens
if you do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard: FATAL: password au
On 09/04/2016 08:11 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
But the message you sent me offlist showed the 9.5 instance running.
But now it's not running.
How are you starting the instance?
As superuser poostgres: pg_ctl start -D /var/lib/pgsql/data &
After
Hi
On 09/04/2016 05:16 PM, Charles Clavadetscher wrote:
Hi
On 09/04/2016 05:14 PM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens
if you do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rs
Hi
On 09/04/2016 05:14 PM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens
if you do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard: FATAL: passwor
Hello
On 09/04/2016 05:11 PM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
But the message you sent me offlist showed the 9.5 instance running.
But now it's not running.
How are you starting the instance?
As superuser poostgres: pg_ctl start -D /var/lib/pgsql/data &
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens if you
do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard:
FATAL: password authentication failed for user "rshepard"
DE
On Sun, 4 Sep 2016, Adrian Klaver wrote:
But the message you sent me offlist showed the 9.5 instance running.
But now it's not running.
How are you starting the instance?
As superuser poostgres: pg_ctl start -D /var/lib/pgsql/data &
After removing an orphaned postmaster.pid the abov
On 09/04/2016 07:07 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
The above is not possible. If the postmaster was not running there
would be no rejection error.
Adrian,
Yes. I conflated when the postmaster was running -- using the 9.3.4
server
-- and now when it's not r
On 09/04/2016 07:08 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Are you able to connect to the new instance with any user at all, e.g.
with psql? If so you can use the command \du to list all users.
Charles,
No. The postmaster is not running; trying to start it
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Actually you already have. From an email that I just realized was offlist:
"As superuser postgres connected to 9.5.4 'psql -l' shows all databases
loaded:
xxx | rshepard | UTF8 | C | en_US.UTF-8 |
xxx| rshepard | UTF8
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Are you able to connect to the new instance with any user at all, e.g.
with psql? If so you can use the command \du to list all users.
Charles,
No. The postmaster is not running; trying to start it requires a password
which is also rejected.
On 09/04/2016 05:40 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Does the user rshepard exist in the new 9.5 instance?
I assume so but do not know how to check this.
Actually you already have. From an email that I just realized was offlist:
"As superuser postg
On Sun, 4 Sep 2016, Adrian Klaver wrote:
The above is not possible. If the postmaster was not running there would be
no rejection error.
Adrian,
Yes. I conflated when the postmaster was running -- using the 9.3.4 server
-- and now when it's not running. Now I'm wondering if I mistakenly use
On 09/04/2016 06:26 AM, Rich Shepard wrote:
Ccing list
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Well the pg_dumpall *.sql file has the global
information(users/passwords), so it is a chicken and egg problem.
FYI, you can do:
pg_dumpall -g
https://www.postgresql.org/docs/9.5/static/app-pg-dum
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Does the user rshepard exist in the new 9.5 instance?
I assume so but do not know how to check this.
Rich
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
Hello
On 09/04/2016 01:16 AM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens
if you do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard: psql: FATAL:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
I am guessing this from before you managed to get the dump file to load and
populate the appropriate tables with user information from the old Postgres
instance.
Could well be the case. Tomorrow will try removing all user-generated
databases and re-r
On 09/03/2016 04:16 PM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens
if you do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard: psql: FATAL: passw
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens if you
do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard:
psql: FATAL: password authentication failed for user "rshepar
On 09/03/2016 04:01 PM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Once you verify that the new instance is running and you can connect
to it then:
Shut down 9.3.4 using pg_ctl stop as user postgres. Started 9.5.4 as user
postgres using 'pg_ctl start /var/lib/pgsql/9.5/dat
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Once you verify that the new instance is running and you can connect to it
then:
Shut down 9.3.4 using pg_ctl stop as user postgres. Started 9.5.4 as user
postgres using 'pg_ctl start /var/lib/pgsql/9.5/data &'.
psql -U some_user -d postgres -p 5442
On 09/03/2016 03:43 PM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
A question are you really using 9.4.5 or 9.5.4(the latest version of
9.5)?
And if you want to use 9.4 I would say use the latest(9.4.9).
Adrian,
It is 9.4.5, but I have the source tarball for 9.5.4 in the
On Sat, 3 Sep 2016, Adrian Klaver wrote:
A question are you really using 9.4.5 or 9.5.4(the latest version of 9.5)?
And if you want to use 9.4 I would say use the latest(9.4.9).
Adrian,
It is 9.4.5, but I have the source tarball for 9.5.4 in the build
directory.
If the above is a yes, any
On 09/03/2016 02:44 PM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
No it says you are using the 9.4.5 version of psql to connect to a
9.3.4 server. psql is available independent of the server running. You
will need to see if both servers are running by doing something like:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
No it says you are using the 9.4.5 version of psql to connect to a 9.3.4
server. psql is available independent of the server running. You will need to
see if both servers are running by doing something like:
Adrian,
Yeah, that's what it said. :-(
On 09/03/2016 02:19 PM, Rich Shepard wrote:
Postgres-9.3.4 was built directly from the web site download source. It's
installed in /usr/lib/postgresql/9.3.4/. Postgresql-9.4.5 was built from
the
SlackBuilds.org script and installed in /usr/lib/postgresql/9.4/. The bin/
subdirectory of the 9.4 v
42 matches
Mail list logo
