Hi,
On Sun, Aug 22, 2010 at 09:18:12PM -0600, Serge Dubrouski wrote:
> Thanks, Hideo! Of course it does need that shift operator there.
> Thanks for checking and catching it!
Both patches pushed. Thanks!
Dejan
> 2010/8/22 :
> > Hi Serge,
> >
> > Thanks!!
> >
> > I confirmed your patch in postg
Thanks, Hideo! Of course it does need that shift operator there.
Thanks for checking and catching it!
2010/8/22 :
> Hi Serge,
>
> Thanks!!
>
> I confirmed your patch in postgresql-8.4.4 on RHEL5.5.
> Of course it combined Cluster-Resource-Agents-784385d01d0f.tar and confirmed
> it.
>
> There wer
Hi Serge,
Thanks!!
I confirmed your patch in postgresql-8.4.4 on RHEL5.5.
Of course it combined Cluster-Resource-Agents-784385d01d0f.tar and confirmed it.
There were some problems to your patch.
I revised it as follows.
runasowner() {
local quietrun=""
[ "x$1" = "x-q" ] && {
qu
Hi Serge,
Thank you for a patch.
I test a patch and will report a result next week.
> Hideo-san, I don't think that we need to introduce a new parameter to
> control verbosity of monitor. There is nothing really important in
> that output.
All right.
I agree that I do not give the log of monito
Ok, attached are 2 patches for pgsql RA. First adds use for the new
"-q" option of ocf_run. Second fixes "meta-data" method plus there is
a rather deep analysis of exit code
Hideo-san, I don't think that we need to introduce a new parameter to
control verbosity of monitor. There is nothing really
Hi,
On Thu, Aug 19, 2010 at 08:43:38AM -0600, Serge Dubrouski wrote:
> Ahh, thanks. I've got where is the problem, and just wonder if apache
> RA suffers from the same issue.
>
> While it is possible to fix this in RA by not calling get_pgsql_param
> if the script was called with for "meta-data"
Ahh, thanks. I've got where is the problem, and just wonder if apache
RA suffers from the same issue.
While it is possible to fix this in RA by not calling get_pgsql_param
if the script was called with for "meta-data" (and in this case that
will be impossible to provide correct default value for
Hi Serge,
Thank you for comment.
My English interpretation may be wrong, but comments.
$OCF_RESKEY_config is not handed to pgsql even if I set right
$OCF_RESKEY_config in the case of the
meta-data processing.
static char*
get_resource_meta(const char* rsc_type, const char* provider)
{
Hello Hideo -
I'm a bit lost with this info. If I understand you correct your
postgresql.conf isn't in /var/lib/pgsql directory and pgsql RA script
can't find it if $OCF_RESKEY_config isn't set. Then why not to just
simply set $OCF_RESKEY_config and point it to correct place instead of
introducing
Hi All,
We confirmed that an error of pgsql occurred by the setting that we did not use
logd for.
When we use a syslog, this occurs.
And when $OCF_RESKEY_config is handled by default, an error occurs when
meta-data processing is
performed.
* OCF_RESKEY_config of the user will not be /var/lib/pg
10 matches
Mail list logo
