You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Especially after restoring from a backup, it's important to know a database role to use, otherwise it's not actually possible to connect to the database. For example, a cluster created as system user gavin will have a superuser role, by default, also named gavin. If this cluster is restored in another account, say bobby, then pgdo will not be able to connect to the restored cluster.
A superuser role can be determined in single-user mode like so:
$ postgres --single -D cluster postgres \
> <<<'select rolname from pg_roles where rolsuper and rolcanlogin' \
> 2> /dev/null | sed 's/^.*\brolname\s*=\s*"\(.*\)".*/\1/p;d'gavin
(Update: function that does this added as cluster::determine_superuser_role_names.)
so pgdo could use this to guess, but perhaps something more/different can be done to make it Just Work.
Note, this might all be moot if pg_hba.conf doesn't allow local connections, for example.
The text was updated successfully, but these errors were encountered:
Especially after restoring from a backup, it's important to know a database role to use, otherwise it's not actually possible to connect to the database. For example, a cluster created as system user gavin will have a superuser role, by default, also named gavin. If this cluster is restored in another account, say bobby, then pgdo will not be able to connect to the restored cluster.
A superuser role can be determined in single-user mode like so:
(Update: function that does this added as
cluster::determine_superuser_role_names
.)so pgdo could use this to guess, but perhaps something more/different can be done to make it Just Work.
Note, this might all be moot if
pg_hba.conf
doesn't allow local connections, for example.The text was updated successfully, but these errors were encountered: