postgres-xc-developers Mailing List for Postgres-XC (Page 127)

Please let me know your sourceforge account name.   You need access pribilege to the resource.

Regards;
---
Koichi


On Tue, 5 Apr 2011 11:00:50 +0530
Ashutosh Bapat <ash...@en...> wrote:

> On Mon, Apr 4, 2011 at 6:56 AM, Koichi Suzuki <ko...@in...>wrote:
> 
> > Hi, Ashutosh;
> >
> > Welcome to the project!  It's so nice that you are already familiar with
> > the internal.
> >
> >
> Thanks Suzuki-san. Looking forward to contribute to this wonderful project.
> 
> 
> > Best Regards;
> > ---
> > Koichi Suzuki
> >
> > On Fri, 1 Apr 2011 17:10:45 +0530
> > Ashutosh Bapat <ash...@en...> wrote:
> >
> > > Hi Michael,
> > > You want to make sure that the user which makes connection to data nodes
> > has
> > > privileges to execute set role on data node. I think, not everyone is
> > > allowed to execute 'set role' using any user name.
> > >
> > > On Fri, Apr 1, 2011 at 4:59 PM, Michael Paquier
> > > <mic...@gm...>wrote:
> > >
> > > > Just another point. XC is using session user to build pooler
> > connections.
> > > > When you change the current user with set role, the same session
> > > > connections are being used, but access to data or tables is managed by
> > > > Coordinators with current user value.
> > > >
> > > > --
> > > > Thanks,
> > > >
> > > > Michael Paquier
> > > > http://michael.otacoo.com
> > > >
> > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > Create and publish websites with WebMatrix
> > > > Use the most popular FREE web apps or write code yourself;
> > > > WebMatrix provides all the features you need to develop and
> > > > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> > > >
> > > > _______________________________________________
> > > > Postgres-xc-developers mailing list
> > > > Pos...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> > > >
> > > >
> > >
> > >
> > > --
> > > Best Wishes,
> > > Ashutosh Bapat
> >
> 
> 
> 
> -- 
> Best Wishes,
> Ashutosh Bapat

On Mon, Apr 4, 2011 at 6:56 AM, Koichi Suzuki <ko...@in...>wrote:

> Hi, Ashutosh;
>
> Welcome to the project!  It's so nice that you are already familiar with
> the internal.
>
>
Thanks Suzuki-san. Looking forward to contribute to this wonderful project.


> Best Regards;
> ---
> Koichi Suzuki
>
> On Fri, 1 Apr 2011 17:10:45 +0530
> Ashutosh Bapat <ash...@en...> wrote:
>
> > Hi Michael,
> > You want to make sure that the user which makes connection to data nodes
> has
> > privileges to execute set role on data node. I think, not everyone is
> > allowed to execute 'set role' using any user name.
> >
> > On Fri, Apr 1, 2011 at 4:59 PM, Michael Paquier
> > <mic...@gm...>wrote:
> >
> > > Just another point. XC is using session user to build pooler
> connections.
> > > When you change the current user with set role, the same session
> > > connections are being used, but access to data or tables is managed by
> > > Coordinators with current user value.
> > >
> > > --
> > > Thanks,
> > >
> > > Michael Paquier
> > > http://michael.otacoo.com
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Create and publish websites with WebMatrix
> > > Use the most popular FREE web apps or write code yourself;
> > > WebMatrix provides all the features you need to develop and
> > > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> > >
> > > _______________________________________________
> > > Postgres-xc-developers mailing list
> > > Pos...@li...
> > > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> > >
> > >
> >
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
>



-- 
Best Wishes,
Ashutosh Bapat

I found a test case in create_view that fails like this:
CREATE SCHEMA testviewschm2;
SET search_path TO testviewschm2, public;
CREATE TABLE t1 (num int, name text);
DROP SCHEMA testviewschm2 CASCADE;
template1=# CREATE TABLE t1 (num int, name text);
ERROR: relation "t1" already exists

This has consequences on other test cases like join that use relations
called t1.
Supporting such things will really reduce the number of diff in regressions.

On Mon, Apr 4, 2011 at 10:29 AM, Koichi Suzuki <ko...@in...>wrote:

> I have just a concern on this series of "SET" command discussion.
> Last year, this was assigned to Andrei but after the review to prioritize
> what to do next in March, we've dropped this from this fiscal years issue
> list because others seemed to be more important.
>
> Should we give higher priority to this?   Then what should we trade?
>
Is it really necessary to trade that? I already wrote a patch :)
As Abbas is saying, I did that primarily to reduce regression diffs, and I
feel that this way of managing SET is pretty nice, isn't it?
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

I understood.   Thank you for reminding.
----------
Koichi Suzuki



2011/4/4 Abbas Butt <abb...@te...>:
> In fact Michael is doing this in an effort to clean regression failures.
> Perhaps we can have a discussion on what work would be required to make a
> test case pass, and then prioritize them and work on them according to
> priority.
> Regards
> Abbas
> On Mon, Apr 4, 2011 at 6:29 AM, Koichi Suzuki <ko...@in...>
> wrote:
>>
>> I have just a concern on this series of "SET" command discussion.
>>
>> Last year, this was assigned to Andrei but after the review to prioritize
>> what to do next in March, we've dropped this from this fiscal years issue
>> list because others seemed to be more important.
>>
>> Should we give higher priority to this?   Then what should we trade?
>>
>> Regards;
>> ---
>> Koichi
>>
>> On Sun, 3 Apr 2011 05:33:27 +0900
>> Michael Paquier <mic...@gm...> wrote:
>>
>> > Hi all,
>> >
>> > I wanted to have everyone's opinion about what to do for the support of
>> > command SET.
>> > I am pretty preoccupied about this support as it has a lot of
>> > consequences
>> > on regression tests.
>> >
>> > Here are the set commands:
>> > SET ROLE, SET CONSTRAINT, SET
>> >
>> > There are also options to do a set for LOCAL (set by the end of current
>> > transaction) and SESSION (set as long as the session as alive).
>> > As far as I could see, it is necessary to make the management of SET
>> > through
>> > the pooler.
>> > When a SET command is issued, the pooler has to pick up the command and
>> > apply it to each connection of the pooler agent holding connections to
>> > backends.
>> >
>> > For local parameters, such parameters have to be changed when
>> > transaction is
>> > committed, and now XC does not do anything with pooler at commit... So
>> > perhaps it may be OK not to do anything for local parameters for the
>> > time
>> > being but just to focus on session parameters. This is at least OK for
>> > the
>> > first implementation step I think.
>> >
>> > Question: is there a libpq API or something that may help to pass down
>> > the
>> > parameter through the connection to the backend?
>> > And with this API the session parameter is alive as long as the
>> > connection
>> > is not cut.
>> > Pooler holds a connection pointer. I was thinking about putting a kind
>> > of
>> > flag on the pooler agent that would permit to identify which agent had
>> > been
>> > modified by a SET command.
>> > With this flag, it may be easy to manage session parameter. Isn't it
>> > enough
>> > to cut the connections on pooler that have been modified by session
>> > parameters when session is cut instead of putting them back to pooler?
>> >
>> > The problem is what can be used to modify a session parameter for a
>> > specific
>> > connection that is hold by the pointer?
>> > Does anyone have any idea or suggestion?
>> > --
>> > Thanks,
>> >
>> > Michael Paquier
>> > http://michael.otacoo.com
>>
>>
>> ------------------------------------------------------------------------------
>> Create and publish websites with WebMatrix
>> Use the most popular FREE web apps or write code yourself;
>> WebMatrix provides all the features you need to develop and
>> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>

In fact Michael is doing this in an effort to clean regression failures.
Perhaps we can have a discussion on what work would be required to make a
test case pass, and then prioritize them and work on them according to
priority.
Regards
Abbas

On Mon, Apr 4, 2011 at 6:29 AM, Koichi Suzuki <ko...@in...>wrote:

> I have just a concern on this series of "SET" command discussion.
>
> Last year, this was assigned to Andrei but after the review to prioritize
> what to do next in March, we've dropped this from this fiscal years issue
> list because others seemed to be more important.
>
> Should we give higher priority to this?   Then what should we trade?
>
> Regards;
> ---
> Koichi
>
> On Sun, 3 Apr 2011 05:33:27 +0900
> Michael Paquier <mic...@gm...> wrote:
>
> > Hi all,
> >
> > I wanted to have everyone's opinion about what to do for the support of
> > command SET.
> > I am pretty preoccupied about this support as it has a lot of
> consequences
> > on regression tests.
> >
> > Here are the set commands:
> > SET ROLE, SET CONSTRAINT, SET
> >
> > There are also options to do a set for LOCAL (set by the end of current
> > transaction) and SESSION (set as long as the session as alive).
> > As far as I could see, it is necessary to make the management of SET
> through
> > the pooler.
> > When a SET command is issued, the pooler has to pick up the command and
> > apply it to each connection of the pooler agent holding connections to
> > backends.
> >
> > For local parameters, such parameters have to be changed when transaction
> is
> > committed, and now XC does not do anything with pooler at commit... So
> > perhaps it may be OK not to do anything for local parameters for the time
> > being but just to focus on session parameters. This is at least OK for
> the
> > first implementation step I think.
> >
> > Question: is there a libpq API or something that may help to pass down
> the
> > parameter through the connection to the backend?
> > And with this API the session parameter is alive as long as the
> connection
> > is not cut.
> > Pooler holds a connection pointer. I was thinking about putting a kind of
> > flag on the pooler agent that would permit to identify which agent had
> been
> > modified by a SET command.
> > With this flag, it may be easy to manage session parameter. Isn't it
> enough
> > to cut the connections on pooler that have been modified by session
> > parameters when session is cut instead of putting them back to pooler?
> >
> > The problem is what can be used to modify a session parameter for a
> specific
> > connection that is hold by the pointer?
> > Does anyone have any idea or suggestion?
> > --
> > Thanks,
> >
> > Michael Paquier
> > http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

I have just a concern on this series of "SET" command discussion.

Last year, this was assigned to Andrei but after the review to prioritize what to do next in March, we've dropped this from this fiscal years issue list because others seemed to be more important.

Should we give higher priority to this?   Then what should we trade?

Regards;
---
Koichi

On Sun, 3 Apr 2011 05:33:27 +0900
Michael Paquier <mic...@gm...> wrote:

> Hi all,
> 
> I wanted to have everyone's opinion about what to do for the support of
> command SET.
> I am pretty preoccupied about this support as it has a lot of consequences
> on regression tests.
> 
> Here are the set commands:
> SET ROLE, SET CONSTRAINT, SET
> 
> There are also options to do a set for LOCAL (set by the end of current
> transaction) and SESSION (set as long as the session as alive).
> As far as I could see, it is necessary to make the management of SET through
> the pooler.
> When a SET command is issued, the pooler has to pick up the command and
> apply it to each connection of the pooler agent holding connections to
> backends.
> 
> For local parameters, such parameters have to be changed when transaction is
> committed, and now XC does not do anything with pooler at commit... So
> perhaps it may be OK not to do anything for local parameters for the time
> being but just to focus on session parameters. This is at least OK for the
> first implementation step I think.
> 
> Question: is there a libpq API or something that may help to pass down the
> parameter through the connection to the backend?
> And with this API the session parameter is alive as long as the connection
> is not cut.
> Pooler holds a connection pointer. I was thinking about putting a kind of
> flag on the pooler agent that would permit to identify which agent had been
> modified by a SET command.
> With this flag, it may be easy to manage session parameter. Isn't it enough
> to cut the connections on pooler that have been modified by session
> parameters when session is cut instead of putting them back to pooler?
> 
> The problem is what can be used to modify a session parameter for a specific
> connection that is hold by the pointer?
> Does anyone have any idea or suggestion?
> -- 
> Thanks,
> 
> Michael Paquier
> http://michael.otacoo.com

Hi, Ashutosh;

Welcome to the project!  It's so nice that you are already familiar with the internal.

Best Regards;
---
Koichi Suzuki

On Fri, 1 Apr 2011 17:10:45 +0530
Ashutosh Bapat <ash...@en...> wrote:

> Hi Michael,
> You want to make sure that the user which makes connection to data nodes has
> privileges to execute set role on data node. I think, not everyone is
> allowed to execute 'set role' using any user name.
> 
> On Fri, Apr 1, 2011 at 4:59 PM, Michael Paquier
> <mic...@gm...>wrote:
> 
> > Just another point. XC is using session user to build pooler connections.
> > When you change the current user with set role, the same session
> > connections are being used, but access to data or tables is managed by
> > Coordinators with current user value.
> >
> > --
> > Thanks,
> >
> > Michael Paquier
> > http://michael.otacoo.com
> >
> >
> > ------------------------------------------------------------------------------
> > Create and publish websites with WebMatrix
> > Use the most popular FREE web apps or write code yourself;
> > WebMatrix provides all the features you need to develop and
> > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> >
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
> >
> 
> 
> -- 
> Best Wishes,
> Ashutosh Bapat

Year, SET ROLE is introduced in PG 8.2 (or 8.1?) so it is very old one. 

Because there are so many options in "SET" command, I think it is not practical to manage all these by long sequence of many SET commands.   For efficiency, we can think about sending set of options by bitmaps and serialized set of options by dedicated command from Coordinator to Datanode through the pooler so that we can set connection options efficiently (with much less overhead).

I hope this kind of shortcut will make pooler more flexible to deal with various connections options as needed by applications.

Regards;
---
Koichi

On Fri, 1 Apr 2011 20:25:53 +0900
Michael Paquier <mic...@gm...> wrote:

> > Are you saying only superusers can make password-less login ? I doubt
> > if its really the case or it has more to do with the pg_hba.conf
> > setting. Can you please check ?
> >
> No, normal users also can make a normal login. I checked that.
> 
> > Another thing I am worried about is that this would increase the
> > number of connections to the data node because there will be a
> > separate connection for each user. Did we check if we can make use of
> > SET ROLE facility to use a single connection for multiple users ?
> >
> Yeah, exactly, if users log in with different user names the database pool
> will be different for each user. This increases the number of connections to
> datanodes.
> 
> Well, I didn't make any checks for SET ROLE when finishing the
> implementation, but it looks to work correctly.
> ioltas@oltania:~/pgsql$ psql template1
> psql (9.0.3)
> Type "help" for help.
> template1=# create table aa (a int);
> CREATE TABLE
> template1=# set role toto;
> SET
> template1=> select * from aa;
> ERROR:  permission denied for relation aa
> template1=> set role ioltas;
> SET
> template1=# select * from aa;
>  a
> ---
> (0 rows)
> 
> SET has only effects on Coordinator, but also GRANT is effective on
> Coordinator so permissions are not a problem. And both users use the same
> connections. I checked.
> -- 
> Thanks,
> 
> Michael Paquier
> http://michael.otacoo.com

HI all,

Please find attached a patch for the support of session parameters in XC.
This patch supports both LOCAL and SESSION parameters through the pooler.

When a SET command is executed on Coordinator, pooler executes this command
on the connections it holds in the pooler agent for the session in an
asynchronous way.
The command is also saved in agent such as when new connectionsare acquired
for this agent on pooler, the pooler is able to replay the SET commands
launched previously, for both local and session parameters if necessary.

When user finishes a transaction, connections are not sent back to pool if
session parameter have been launched, and the list of session parameters is
kept saved in the pooler agent.
However, the list of local parameters is reset each time a transaction is
finished.

When a user logs out from Coordinator, the list of connections that this
user used for XC transactions are put back to pull after launching a "RESET
ALL" query on each connection to be sure to reset everything.

There is still in this patch a bug when logging out.
If assertions are enabled, Coordinator crashes but I am looking into that.

This patch does not take into account user-default session parameters but
this code can easily be used as a base for this extension, but this may be a
next step.

Also note that I haven't taken the time to test this patch with regressions,
so there may be some other issues.
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

I made a couple of checks.

The following case, described in bug 3269894, works with the patch attached.
CREATE SCHEMA testviewschm2;
SET search_path TO testviewschm2, public;
CREATE TABLE t1 (num int, name text);
DROP SCHEMA testviewschm2 CASCADE;
CREATE TABLE t1 (num int, name text);

This one doesn't work though:
CREATE SCHEMA testviewschm2;
SET LOCAL search_path TO testviewschm2, public;
CREATE TABLE t1 (num int, name text);
DROP SCHEMA testviewschm2 CASCADE;
CREATE TABLE t1 (num int, name text);

The only point to finish the support of session parameters may be to
disconnect the connections that had their session parameters modified
instead of put them back to pool.
Then for the time being, blocking LOCAL parameters may be a good choice.
Comments?
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Hi all,

I wanted to have everyone's opinion about what to do for the support of
command SET.
I am pretty preoccupied about this support as it has a lot of consequences
on regression tests.

Here are the set commands:
SET ROLE, SET CONSTRAINT, SET

There are also options to do a set for LOCAL (set by the end of current
transaction) and SESSION (set as long as the session as alive).
As far as I could see, it is necessary to make the management of SET through
the pooler.
When a SET command is issued, the pooler has to pick up the command and
apply it to each connection of the pooler agent holding connections to
backends.

For local parameters, such parameters have to be changed when transaction is
committed, and now XC does not do anything with pooler at commit... So
perhaps it may be OK not to do anything for local parameters for the time
being but just to focus on session parameters. This is at least OK for the
first implementation step I think.

Question: is there a libpq API or something that may help to pass down the
parameter through the connection to the backend?
And with this API the session parameter is alive as long as the connection
is not cut.
Pooler holds a connection pointer. I was thinking about putting a kind of
flag on the pooler agent that would permit to identify which agent had been
modified by a SET command.
With this flag, it may be easy to manage session parameter. Isn't it enough
to cut the connections on pooler that have been modified by session
parameters when session is cut instead of putting them back to pooler?

The problem is what can be used to modify a session parameter for a specific
connection that is hold by the pointer?
Does anyone have any idea or suggestion?
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

>
> If you don't execute SET ROLE on the datanode connections, you would
> continue accessing the data with the connection user who may not have
> enough access rights to access the data.
>
OK, I see, so we need to push down this parameter, but also we need to
maintain the connections alive between coordinator and Datanodes to keep the
session on.

Well, this is a part of the implementation of session parameters.
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Hi Michael,
You want to make sure that the user which makes connection to data nodes has
privileges to execute set role on data node. I think, not everyone is
allowed to execute 'set role' using any user name.

On Fri, Apr 1, 2011 at 4:59 PM, Michael Paquier
<mic...@gm...>wrote:

> Just another point. XC is using session user to build pooler connections.
> When you change the current user with set role, the same session
> connections are being used, but access to data or tables is managed by
> Coordinators with current user value.
>
> --
> Thanks,
>
> Michael Paquier
> http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
Best Wishes,
Ashutosh Bapat

On Fri, Apr 1, 2011 at 5:25 PM, Michael Paquier
<mic...@gm...> wrote:
> Hi,
>
> On Fri, Apr 1, 2011 at 8:40 PM, Ashutosh Bapat
> <ash...@en...> wrote:
>>
>> Hi Michael,
>> You want to make sure that the user which makes connection to data nodes
>> has privileges to execute set role on data node. I think, not everyone is
>> allowed to execute 'set role' using any user name.
>
> Yes indeed, it may be necessary to execute also set role on Datanodes,
> but as long as the application only needs to connect to Coordinators,
> executing set role only on the coordinator where session is is not enough?
>
> For the execution of set role, I am not really familiar with that but I
> would think it depends on the rights a role have when it has been defined or
> altered with CREATE/ALTER ROLE.
> On Coordinator, XC uses uses the same protocol as postgres, so I think it
> may be OK to have set role only executed on Coordinator, no?


If you don't execute SET ROLE on the datanode connections, you would
continue accessing the data with the connection user who may not have
enough access rights to access the data.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

Hi,

On Fri, Apr 1, 2011 at 8:40 PM, Ashutosh Bapat <
ash...@en...> wrote:

> Hi Michael,
> You want to make sure that the user which makes connection to data nodes
> has privileges to execute set role on data node. I think, not everyone is
> allowed to execute 'set role' using any user name.
>
Yes indeed, it may be necessary to execute also set role on Datanodes,
but as long as the application only needs to connect to Coordinators,
executing set role only on the coordinator where session is is not enough?

For the execution of set role, I am not really familiar with that but I
would think it depends on the rights a role have when it has been defined or
altered with CREATE/ALTER ROLE.
On Coordinator, XC uses uses the same protocol as postgres, so I think it
may be OK to have set role only executed on Coordinator, no?

~$ psql -U toto -p 5452 template1
psql (9.0.3)
template1=> set role ioltas; -- superuser
ERROR:  permission denied to set role "ioltas"
template1=> select usename,usesuper from pg_user;
 usename | usesuper
---------+----------
 ioltas  | t
 toto    | f
(2 rows)
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Just another point. XC is using session user to build pooler connections.
When you change the current user with set role, the same session connections
are being used, but access to data or tables is managed by Coordinators with
current user value.
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

> Are you saying only superusers can make password-less login ? I doubt
> if its really the case or it has more to do with the pg_hba.conf
> setting. Can you please check ?
>
No, normal users also can make a normal login. I checked that.

> Another thing I am worried about is that this would increase the
> number of connections to the data node because there will be a
> separate connection for each user. Did we check if we can make use of
> SET ROLE facility to use a single connection for multiple users ?
>
Yeah, exactly, if users log in with different user names the database pool
will be different for each user. This increases the number of connections to
datanodes.

Well, I didn't make any checks for SET ROLE when finishing the
implementation, but it looks to work correctly.
ioltas@oltania:~/pgsql$ psql template1
psql (9.0.3)
Type "help" for help.
template1=# create table aa (a int);
CREATE TABLE
template1=# set role toto;
SET
template1=> select * from aa;
ERROR:  permission denied for relation aa
template1=> set role ioltas;
SET
template1=# select * from aa;
 a
---
(0 rows)

SET has only effects on Coordinator, but also GRANT is effective on
Coordinator so permissions are not a problem. And both users use the same
connections. I checked.
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Hi Michael,

Are you saying only superusers can make password-less login ? I doubt
if its really the case or it has more to do with the pg_hba.conf
setting. Can you please check ?

Another thing I am worried about is that this would increase the
number of connections to the data node because there will be a
separate connection for each user. Did we check if we can make use of
SET ROLE facility to use a single connection for multiple users ?

Thanks,
Pavan

On Fri, Apr 1, 2011 at 12:22 PM, Koichi Suzuki <koi...@gm...> wrote:
> Okay.   Only a superuser can issue this.   You can commit this patch.
>
> In the future, normal user may want to clean connection assigned to
> the current coordinator backend.   I think we can use this syntax,
> without "FOR DATABASE" and "TO USER".
> ----------
> Koichi Suzuki
>
>
>
> 2011/4/1 Michael Paquier <mic...@gm...>:
>> OK I see.
>> So the query will become something like:
>> CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } [ FOR
>> DATABASE dbname ] [TO user_name];
>>
>> Even if Database and user name are not mandatory, at least one of them is
>> necessary to perform a cleanup.
>>
>> Are you OK if I commit the pooler patch first?
>>
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>



-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

Okay.   Only a superuser can issue this.   You can commit this patch.

In the future, normal user may want to clean connection assigned to
the current coordinator backend.   I think we can use this syntax,
without "FOR DATABASE" and "TO USER".
----------
Koichi Suzuki



2011/4/1 Michael Paquier <mic...@gm...>:
> OK I see.
> So the query will become something like:
> CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } [ FOR
> DATABASE dbname ] [TO user_name];
>
> Even if Database and user name are not mandatory, at least one of them is
> necessary to perform a cleanup.
>
> Are you OK if I commit the pooler patch first?
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
>

OK I see.
So the query will become something like:
CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } [ FOR
DATABASE dbname ] [TO user_name];

Even if Database and user name are not mandatory, at least one of them is
necessary to perform a cleanup.

Are you OK if I commit the pooler patch first?

-- 
Michael Paquier
http://michael.otacoo.com

I think it is more friendly if we can omit "FOR DATABASE" so that all
the connections assigned to the specified user are cleaned.  Or users
may want to have an option to clean connection connected to the
coordinator backend in use.
----------
Koichi Suzuki



2011/4/1 Michael Paquier <mic...@gm...>:
> No, not yet.
> But I can also write a small extension of CLEAN CONNECTION with:
> CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } FOR DATABASE
> dbname [TO user_name];
>
> The extension being [TO user_name]. If nothing is specified, cleaning is
> made for all the roles on this database.
>
> Is it OK to do such an extension only once the 1st patch is committed?
>
> On Fri, Apr 1, 2011 at 9:46 AM, Koichi Suzuki <koi...@gm...> wrote:
>>
>> I think it's a great step.   Can we clean the connection handling
>> specific user/role, not datanode?
>>
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2011/4/1 Michael Paquier <mic...@gm...>:
>> > Hi,
>> >
>> > I took the time to make a couple of tests with the patch attached which
>> > is
>> > the latest version.
>> > As it is not necessary to set password values in connection strings for
>> > users to have an access to the data in the cluster, I removed that in
>> > the
>> > patch attached, making it a little bit simplified.
>> >
>> > Besides, I made a couple of tests with several users in the cluster.
>> > I made it with a cluster having 2 Coordinators, with ports 5432 (Co1)
>> > and
>> > 5452 (Co2).
>> > The 2 users are called ioltas and toto.
>> >
>> > 1) After building the cluster, if the role is not created:
>> > toto@oltania:~$ psql -p 5452 template1
>> > psql: FATAL:  role "toto" does not exist
>> >
>> > 2) ioltas is a superuser, so it creates a new role and a table from
>> > Coordinator 1:
>> > ioltas@oltania:~/pgsql$ psql template1
>> > psql (9.0.3)
>> > Type "help" for help.
>> > template1=# create role toto login;
>> > CREATE ROLE
>> > template1=# create table aa (a int);
>> > CREATE TABLE
>> > template1=# insert into aa values (1),(2);
>> > INSERT 0 2
>> >
>> > 3) then toto can login but cannot access the table:
>> > toto@oltania:~$ psql -p 5452 template1
>> > psql (9.0.3)
>> > Type "help" for help.
>> > template1=> select * from aa;
>> > ERROR:  permission denied for relation aa
>> > template1=> \dp aa
>> >                           Access privileges
>> >  Schema | Name | Type  | Access privileges | Column access privileges
>> > --------+------+-------+-------------------+--------------------------
>> >  public | aa   | table |                   |
>> > (1 row)
>> >
>> > 4) grant access to the table aa for toto from Coordinator 1 (superuser
>> > ioltas)
>> > template1=# grant select on table aa to toto;
>> > GRANT
>> >
>> > 5) Then table access is granted for user toto:
>> > template1=> \dp aa
>> >                             Access privileges
>> >  Schema | Name | Type  |   Access privileges   | Column access
>> > privileges
>> >
>> > --------+------+-------+-----------------------+--------------------------
>> >  public | aa   | table | ioltas=arwdDxt/ioltas+|
>> >         |      |       | toto=r/ioltas         |
>> > (1 row)
>> > template1=> select * from aa;
>> >  a
>> > ---
>> >  1
>> >  2
>> > (2 rows)
>> >
>> > 6) by doing a ps, connections for both users exist
>> > ioltas@oltania:~/pgxc$ ps ux | grep template1 | cut -d " " -f 30-
>> > ioltas template1 [local] idle
>> > ioltas template1 ::1(55384) idle
>> > ioltas template1 ::1(48039) idle
>> > ioltas template1 ::1(57169) idle
>> > toto template1 [local] idle
>> > toto template1 ::1(55396) idle
>> > toto template1 ::1(48051) idle
>> >
>> > 7) CLEAN CONNECTION  is also available to close pooler connections:
>> > for user toto:
>> > template1=> clean connection to all for database template1;
>> > ERROR:  must be superuser to clean pool connections
>> > for superuser ioltas:
>> > template1=# clean connection to all for database template1;
>> > CLEAN CONNECTION
>> >
>> > CLEAN CONNECTION cleans up connections for all users on the chosen
>> > database.
>> > So, any comments?
>> > --
>> > Michael Paquier
>> > http://michael.otacoo.com
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Create and publish websites with WebMatrix
>> > Use the most popular FREE web apps or write code yourself;
>> > WebMatrix provides all the features you need to develop and
>> > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>> >
>> > _______________________________________________
>> > Postgres-xc-developers mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >
>> >
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
>

No, not yet.
But I can also write a small extension of CLEAN CONNECTION with:
CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } FOR DATABASE
dbname [TO user_name];

The extension being [TO user_name]. If nothing is specified, cleaning is
made for all the roles on this database.

Is it OK to do such an extension only once the 1st patch is committed?

On Fri, Apr 1, 2011 at 9:46 AM, Koichi Suzuki <koi...@gm...> wrote:

> I think it's a great step.   Can we clean the connection handling
> specific user/role, not datanode?
>
> ----------
> Koichi Suzuki
>
>
>
> 2011/4/1 Michael Paquier <mic...@gm...>:
> > Hi,
> >
> > I took the time to make a couple of tests with the patch attached which
> is
> > the latest version.
> > As it is not necessary to set password values in connection strings for
> > users to have an access to the data in the cluster, I removed that in the
> > patch attached, making it a little bit simplified.
> >
> > Besides, I made a couple of tests with several users in the cluster.
> > I made it with a cluster having 2 Coordinators, with ports 5432 (Co1) and
> > 5452 (Co2).
> > The 2 users are called ioltas and toto.
> >
> > 1) After building the cluster, if the role is not created:
> > toto@oltania:~$ psql -p 5452 template1
> > psql: FATAL:  role "toto" does not exist
> >
> > 2) ioltas is a superuser, so it creates a new role and a table from
> > Coordinator 1:
> > ioltas@oltania:~/pgsql$ psql template1
> > psql (9.0.3)
> > Type "help" for help.
> > template1=# create role toto login;
> > CREATE ROLE
> > template1=# create table aa (a int);
> > CREATE TABLE
> > template1=# insert into aa values (1),(2);
> > INSERT 0 2
> >
> > 3) then toto can login but cannot access the table:
> > toto@oltania:~$ psql -p 5452 template1
> > psql (9.0.3)
> > Type "help" for help.
> > template1=> select * from aa;
> > ERROR:  permission denied for relation aa
> > template1=> \dp aa
> >                           Access privileges
> >  Schema | Name | Type  | Access privileges | Column access privileges
> > --------+------+-------+-------------------+--------------------------
> >  public | aa   | table |                   |
> > (1 row)
> >
> > 4) grant access to the table aa for toto from Coordinator 1 (superuser
> > ioltas)
> > template1=# grant select on table aa to toto;
> > GRANT
> >
> > 5) Then table access is granted for user toto:
> > template1=> \dp aa
> >                             Access privileges
> >  Schema | Name | Type  |   Access privileges   | Column access privileges
> >
> --------+------+-------+-----------------------+--------------------------
> >  public | aa   | table | ioltas=arwdDxt/ioltas+|
> >         |      |       | toto=r/ioltas         |
> > (1 row)
> > template1=> select * from aa;
> >  a
> > ---
> >  1
> >  2
> > (2 rows)
> >
> > 6) by doing a ps, connections for both users exist
> > ioltas@oltania:~/pgxc$ ps ux | grep template1 | cut -d " " -f 30-
> > ioltas template1 [local] idle
> > ioltas template1 ::1(55384) idle
> > ioltas template1 ::1(48039) idle
> > ioltas template1 ::1(57169) idle
> > toto template1 [local] idle
> > toto template1 ::1(55396) idle
> > toto template1 ::1(48051) idle
> >
> > 7) CLEAN CONNECTION  is also available to close pooler connections:
> > for user toto:
> > template1=> clean connection to all for database template1;
> > ERROR:  must be superuser to clean pool connections
> > for superuser ioltas:
> > template1=# clean connection to all for database template1;
> > CLEAN CONNECTION
> >
> > CLEAN CONNECTION cleans up connections for all users on the chosen
> database.
> > So, any comments?
> > --
> > Michael Paquier
> > http://michael.otacoo.com
> >
> >
> >
> ------------------------------------------------------------------------------
> > Create and publish websites with WebMatrix
> > Use the most popular FREE web apps or write code yourself;
> > WebMatrix provides all the features you need to develop and
> > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> >
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
> >
>



-- 
Michael Paquier
http://michael.otacoo.com

I think it's a great step.   Can we clean the connection handling
specific user/role, not datanode?

----------
Koichi Suzuki



2011/4/1 Michael Paquier <mic...@gm...>:
> Hi,
>
> I took the time to make a couple of tests with the patch attached which is
> the latest version.
> As it is not necessary to set password values in connection strings for
> users to have an access to the data in the cluster, I removed that in the
> patch attached, making it a little bit simplified.
>
> Besides, I made a couple of tests with several users in the cluster.
> I made it with a cluster having 2 Coordinators, with ports 5432 (Co1) and
> 5452 (Co2).
> The 2 users are called ioltas and toto.
>
> 1) After building the cluster, if the role is not created:
> toto@oltania:~$ psql -p 5452 template1
> psql: FATAL:  role "toto" does not exist
>
> 2) ioltas is a superuser, so it creates a new role and a table from
> Coordinator 1:
> ioltas@oltania:~/pgsql$ psql template1
> psql (9.0.3)
> Type "help" for help.
> template1=# create role toto login;
> CREATE ROLE
> template1=# create table aa (a int);
> CREATE TABLE
> template1=# insert into aa values (1),(2);
> INSERT 0 2
>
> 3) then toto can login but cannot access the table:
> toto@oltania:~$ psql -p 5452 template1
> psql (9.0.3)
> Type "help" for help.
> template1=> select * from aa;
> ERROR:  permission denied for relation aa
> template1=> \dp aa
>                           Access privileges
>  Schema | Name | Type  | Access privileges | Column access privileges
> --------+------+-------+-------------------+--------------------------
>  public | aa   | table |                   |
> (1 row)
>
> 4) grant access to the table aa for toto from Coordinator 1 (superuser
> ioltas)
> template1=# grant select on table aa to toto;
> GRANT
>
> 5) Then table access is granted for user toto:
> template1=> \dp aa
>                             Access privileges
>  Schema | Name | Type  |   Access privileges   | Column access privileges
> --------+------+-------+-----------------------+--------------------------
>  public | aa   | table | ioltas=arwdDxt/ioltas+|
>         |      |       | toto=r/ioltas         |
> (1 row)
> template1=> select * from aa;
>  a
> ---
>  1
>  2
> (2 rows)
>
> 6) by doing a ps, connections for both users exist
> ioltas@oltania:~/pgxc$ ps ux | grep template1 | cut -d " " -f 30-
> ioltas template1 [local] idle
> ioltas template1 ::1(55384) idle
> ioltas template1 ::1(48039) idle
> ioltas template1 ::1(57169) idle
> toto template1 [local] idle
> toto template1 ::1(55396) idle
> toto template1 ::1(48051) idle
>
> 7) CLEAN CONNECTION  is also available to close pooler connections:
> for user toto:
> template1=> clean connection to all for database template1;
> ERROR:  must be superuser to clean pool connections
> for superuser ioltas:
> template1=# clean connection to all for database template1;
> CLEAN CONNECTION
>
> CLEAN CONNECTION cleans up connections for all users on the chosen database.
> So, any comments?
> --
> Michael Paquier
> http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>

Hi,

I took the time to make a couple of tests with the patch attached which is
the latest version.
As it is not necessary to set password values in connection strings for
users to have an access to the data in the cluster, I removed that in the
patch attached, making it a little bit simplified.

Besides, I made a couple of tests with several users in the cluster.
I made it with a cluster having 2 Coordinators, with ports 5432 (Co1) and
5452 (Co2).
The 2 users are called ioltas and toto.

1) After building the cluster, if the role is not created:
toto@oltania:~$ psql -p 5452 template1
psql: FATAL:  role "toto" does not exist

2) ioltas is a superuser, so it creates a new role and a table from
Coordinator 1:
ioltas@oltania:~/pgsql$ psql template1
psql (9.0.3)
Type "help" for help.
template1=# create role toto login;
CREATE ROLE
template1=# create table aa (a int);
CREATE TABLE
template1=# insert into aa values (1),(2);
INSERT 0 2

3) then toto can login but cannot access the table:
toto@oltania:~$ psql -p 5452 template1
psql (9.0.3)
Type "help" for help.
template1=> select * from aa;
ERROR:  permission denied for relation aa
template1=> \dp aa
                          Access privileges
 Schema | Name | Type  | Access privileges | Column access privileges
--------+------+-------+-------------------+--------------------------
 public | aa   | table |                   |
(1 row)

4) grant access to the table aa for toto from Coordinator 1 (superuser
ioltas)
template1=# grant select on table aa to toto;
GRANT

5) Then table access is granted for user toto:
template1=> \dp aa
                            Access privileges
 Schema | Name | Type  |   Access privileges   | Column access privileges
--------+------+-------+-----------------------+--------------------------
 public | aa   | table | ioltas=arwdDxt/ioltas+|
        |      |       | toto=r/ioltas         |
(1 row)
template1=> select * from aa;
 a
---
 1
 2
(2 rows)

6) by doing a ps, connections for both users exist
ioltas@oltania:~/pgxc$ ps ux | grep template1 | cut -d " " -f 30-
ioltas template1 [local] idle
ioltas template1 ::1(55384) idle
ioltas template1 ::1(48039) idle
ioltas template1 ::1(57169) idle
toto template1 [local] idle
toto template1 ::1(55396) idle
toto template1 ::1(48051) idle

7) CLEAN CONNECTION  is also available to close pooler connections:
for user toto:
template1=> clean connection to all for database template1;
ERROR:  must be superuser to clean pool connections
for superuser ioltas:
template1=# clean connection to all for database template1;
CLEAN CONNECTION

CLEAN CONNECTION cleans up connections for all users on the chosen database.
So, any comments?
-- 
Michael Paquier
http://michael.otacoo.com

Thanks for fixing this issue.
Such patches are always very helpful.

Regards,
-- 
Michael Paquier
http://michael.otacoo.com