Need to fix one more glitch in upgrade to -10.2

Поиск
Список
Период
Сортировка
От Rich Shepard
Тема Need to fix one more glitch in upgrade to -10.2
Дата
Msg-id alpine.LNX.2.20.1802171347440.19982@salmo.appl-ecosys.com
обсуждение исходный текст
Ответы Re: Need to fix one more glitch in upgrade to -10.2  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список pgsql-general
Hi folks,

   Today I upgraded from -9.6.6 to -10.2 on my Slackware-14.2 desktop. The
user and group IDs changed from before, but I have that all fixed now.
Starting postgres (as user postgres) succeeded, but the role for me (as a
use and owner of most databases) seems to have become lost during the
transition.

   I try to open a database and see this:

$ psql jerr2018-02-17 13:45:35.852 PST [5839] FATAL:  password authentication failed for user "rshepard"
2018-02-17 13:45:35.852 PST [5839] DETAIL:  Role "rshepard" does not exist.
     Connection matched pg_hba.conf line 80: "local   all             all    md5"
2018-02-17 13:45:35.853 PST [5839] LOG:  could not send data to client: Broken pipe

   So I edited pg_hba.conf to change the method to 'trust' as I'm the only
user on this system. Ran /etc/rc.d/rc.postfix reload and see:

# /etc/rc.postgresql reload
Could not find 'postgres' binary. Maybe PostgreSQL is not installed properly?

   $ ps ax | grep postgres
  5826 pts/0    S      0:00 postgres -D /var/lib/pgsql/10.2/data
  5828 ?        Ss     0:00 postgres: checkpointer process
  5829 ?        Ss     0:00 postgres: writer process
  5830 ?        Ss     0:00 postgres: wal writer process
  5831 ?        Ss     0:00 postgres: autovacuum launcher process
  5832 ?        Ss     0:00 postgres: stats collector process
  5833 ?        Ss     0:00 postgres: bgworker: logical replication launcher

   I would appreciate a pointer on what to check to determine why I cannot
reload postgres to see the changed pg_hba.conf and let me access my
databases.

Regards,

Rich




В списке pgsql-general по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Rationale for PUBLIC having CREATE and USAGE privileges on theschema "public" by default
Следующее
От: Olegs Jeremejevs
Дата:
Сообщение: Re: Rationale for PUBLIC having CREATE and USAGE privileges on theschema "public" by default