Thanks for the reply,
Actually I am not setting Role for database specific,I did set Role to user.
Since users and roles are global for all databases in PostgreSQL,I believe it should work for replication pesudo database.
Thanks,
Chiru
On Sat, Apr 22, 2017 at 12:34 PM, Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
On 04/22/2017 08:13 AM, chiru r wrote:
But, SUPERUSER privileges are working, you can see above I am able to do
CREATEUSER and CREATEDB.
What is the differences in case A and case B for Superuser?
I had flash of insight while driving. The insight being that the problem is down to this:
https://www.postgresql.org/docs/9.6/static/app-pgbasebackup. html
--dbname=connstr
"
Specifies parameters used to connect to the server, as a connection string. See Section 32.1.1 for more information.
The option is called --dbname for consistency with other client applications, but because pg_basebackup doesn't connect to any particular database in the cluster, database name in the connection string will be ignored.
"
Have not looked into the source to see how pg_basebackup connects, however I am guessing what ever it does bypasses the mechanism for doing SET ROLE on connection. In pg_hba the 'dummy' database replication is used for replication connections, which is what pg_basebackup does. Since it is not an actual database there would seem to be no way for the alter user backup_admin set role to dba_admin setting to take effect.
Thanks,
Chiru
On Sat, Apr 22, 2017 at 10:45 AM, David G. Johnston
<david.g.johnston@xxxxxxxxx <mailto:david.g.johnston@gmail.com >> wrote:
On Saturday, April 22, 2017, chiru r <chirupg@xxxxxxxxx
<mailto:chirupg@xxxxxxxxx>> wrote:
Thank you for the reply.
It is inheriting role attributes. I am able to do
CREATEDB,CREATEROLE... etc .
Even i am able to do manual start backup and stop backup also
using *backup_admin.*
**
So I've recently read that while some role attributes are inherited
SUPERUSER is not. Everything you are seeing work or not works
appears to be due to superuser privileges differences.
David J.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
