On Mon, Jan 17, 2011 at 13:14, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 17, 2011 at 12:11, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 17, 2011 at 19:51, Magnus Hagander mag...@hagander.net wrote:
Here's a patch that limits it to superuser only. We can't easily
On Sun, Jan 16, 2011 at 21:57, Josh Berkus j...@agliodbs.com wrote:
I suggest instead either superuser or replication permissions.
That's another idea.
Oh, wait. I take that back ... we're trying to encourage users NOT to
use the replication user as a login, yes?
yeah.
Here's a patch
On Mon, Jan 17, 2011 at 19:51, Magnus Hagander mag...@hagander.net wrote:
Here's a patch that limits it to superuser only. We can't easily match
it to the user of the session given the way the walsender data is
returned - it doesn't contain the user information. But limiting it to
superuser
On Mon, Jan 17, 2011 at 12:11, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 17, 2011 at 19:51, Magnus Hagander mag...@hagander.net wrote:
Here's a patch that limits it to superuser only. We can't easily match
it to the user of the session given the way the walsender data is
I suggest pg_stat_replication do just like pg_stat_activity, which is
return NULL in most fields if the user isn't
(superuser||same_user_as_that_session).
What session would that be, exactly?
I suggest instead either superuser or replication permissions.
--
On Sun, Jan 16, 2011 at 21:51, Josh Berkus j...@agliodbs.com wrote:
I suggest pg_stat_replication do just like pg_stat_activity, which is
return NULL in most fields if the user isn't
(superuser||same_user_as_that_session).
What session would that be, exactly?
The user doing the query to
I suggest instead either superuser or replication permissions.
That's another idea.
Oh, wait. I take that back ... we're trying to encourage users NOT to
use the replication user as a login, yes?
--
-- Josh Berkus
