On 1/30/2007 4:47 PM, Andreas Kostyrka wrote: > * Mark Stosberg <[EMAIL PROTECTED]> [070130 22:40]: >> >> Hello, >> >> The docs in firstdb.sgml say >> >> "The <envar>REPLICATIONUSER</envar> needs to be a &postgres; superuser." >> >> >From my own testing, that doesn't seem to be true. I connect as a user >> that owns the database it's connecting to (and all objects in it), and >> that seems to be sufficient. >> >> I did use the PostgreSQL super-user for the dump/schema restore and >> adding in the PL/pgSQL language, but it doesn't seem to be necessary >> for the ongoing replication process. >> >> (Or have I just not run into a hidden danger of not being a super-user?) > > Well, sarcastically speaking, yes. > > slony does catalog manipulations on the slaves (to disable triggers), > and I'm not sure if you can do that without being a superuser.
Not only does it have to be a superuser to do so, but that user also needs the usecatupd right for precisely that reason. Thus, the db user connecting from slon to the local node has to be a superuser at some times and I don't see the benefit of adding more complexity here. Slon will know the user and password (if required). Where the superuser definitely isn't required is for all the remote connections. Since slon never even updates on a remote connection, one could go so far and grant select privileges on the slony tables only. And you know what the good news is? All that's required to do so is creating the user, doing the grant's and using that user in the login info in sl_path. We don't need to change a single line of code. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] # _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
