Hi Serge,
Hi Vadym,

Sorry.....I am busy. 

However, I agree to an opinion of Serge. 
I add a parameter and think it not to have any problem.

Best Regards,
Hideo Yamauchi.

--- Vadym Chepkov <[email protected]> wrote:

> 
> On Sep 26, 2010, at 1:28 PM, Serge Dubrouski wrote:
> 
> > I've been thinking about changing pgsql RA that way for some time
> > already. That's sounds absolutely logically. The problem though is
> > that it changes current behavior and can potentially break current
> > installations. So before I make any changes I;d like to hear opinion
> > of other users of that RA, especially yours,. Hideo. Here is how I see
> > it:
> > 
> > 1. Implement OCF_RESKEY_monitor_user parameter. If it's set it'll be
> > used for monitoring purposes. If it's not set the script will fall
> > back to the current behavior and use pgdba user for monitoring to make
> > it backward compatible with current installation.
> 
> That what I would expect
> 
> > 
> > 2. Implement OCF_RESKEY_monitor_password parameter. If it's script
> > will check if OCF_RESKEY_monitor_user is set as well. If
> > OCF_RESKEY_monitor_user is null script will fail with
> > OCF_ERR_INSTALLED indicating configuration error, otherway password
> > will be used for monitoring.
> 
> .ocf-returncodes doesn't have good explanation when each return code should 
> be used, 
> why not OCF_ERR_CONFIGURED, just curious? 
> 
> > 
> > 3. Implement OCF_RESKEY_monitor_script parameter. Currently pgsql runs
> > generic "select now();" sql to check that PostgreSQL is alive. One
> > could want to have more sophisticated monitoring that would include
> > select of real data or something else. So if this parameter is set
> > pgsql RA will use it for monitoring, otherway it'll use old generic
> > "select now();"
> 
> This part should depend on OCF_CHECK_LEVEL, imho. 
> 
> Vadym
> 
> > 
> > On Sun, Sep 26, 2010 at 6:27 AM, Vadym Chepkov <[email protected]> wrote:
> >> Hi,
> >> 
> >> pgsql RA is using pgdba parameter for two different functions: as the 
> >> owner of the postmaster
> process and as a database userid for monitor operation.
> >> If postmaster is configured to listen on a cluster IP for the later to 
> >> work I would have to
> allow remote login for the dba user without a password (password is not one 
> of the RA's
> parameters) - not a good idea. I think new couple of parameters should be 
> added: test_user and
> test_passwd (similar to mysql agent) to separate operational and monitoring 
> tasks.
> >> 
> >> Thanks,
> >> Vadym
> >> _______________________________________________
> >> Linux-HA mailing list
> >> [email protected]
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> >> See also: http://linux-ha.org/ReportingProblems
> >> 
> > 
> > 
> > 
> > -- 
> > Serge Dubrouski.
> > _______________________________________________
> > Linux-HA mailing list
> > [email protected]
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > See also: http://linux-ha.org/ReportingProblems
> 
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
> 

_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to