Hi Serge, Thank you for detailed comment.
> 1. Use different pg_dba user. Probably no the best option. > 2. Use different unix_socket_directory variable in postgresql.conf > file for different instances. > 3. Use different pgdb for different instances. > 4. use different pg_host for different instances. By your comment, I was able to do confirmation of the setting. > > I think that a patch of Dejan works definitely. > > It's mine :-) Sorry.... I think that a patch of Serge works definitely. Best Regards, Hideo Yamauchi. --- Serge Dubrouski <[email protected]> wrote: > On Thu, Nov 4, 2010 at 6:55 PM, <[email protected]> wrote: > > Hi All, > > > > Thank you for a lot of comment. > > > >> >> > � � � if [ -f $PIDFILE ] > >> >> > � � � then > >> >> > � � � � � PID=`head -n 1 $PIDFILE` > >> >> > - � � � � kill -s 0 $PID >/dev/null 2>&1 > >> >> > && fuser > > $OCF_RESKEY_pgdata > >> >> > 2>&1 | grep $PID >/dev/null 2>&1 > >> >> > + � � � � runasowner "kill -s 0 $PID > >> >> > >/dev/null 2>&1" > >> >> > � � � � � return $? > >> >> > � � � fi > > > > The change to very beginning fuser was performed with the next patch. > > > > �* http://www.gossamer-threads.com/lists/linuxha/dev/67871 > > I remember perfectly well when and why I put it there :-) I just > didn't have time to rethink it; > > > > Because runasowner uses ocf_run in latest pgsql, I think that RA can > > support some instance of > > postgres. > > To support several instances of PostgreSQL on the same host you have > to somehow split them in the configuration. You have several options > there: > > 1. Use different pg_dba user. Probably no the best option. > 2. Use different unix_socket_directory variable in postgresql.conf > file for different instances. > 3. Use different pgdb for different instances. > 4. use different pg_host for different instances. > > > > > And the patch of Dejan is better than the patch which I suggested. > > > > I think that a patch of Dejan works definitely. > > It's mine :-) > > > > > Best Regards, > > Hideo Yamauchi. > > > > --- Serge Dubrouski <[email protected]> wrote: > > > >> On Thu, Nov 4, 2010 at 2:22 PM, Lars Ellenberg > >> <[email protected]> wrote: > >> > On Thu, Nov 04, 2010 at 04:52:49PM +0100, Dejan Muhamedagic wrote: > >> >> Hi, > >> >> > >> >> On Thu, Nov 04, 2010 at 08:54:02AM -0600, Serge Dubrouski wrote: > >> >> > Honestly I've never liked that fuser. No doubt that it's too expensive > >> >> > to run it in every status/monitor operation. But this proposed > >> >> > solution make pgsql RA incompatible with other operation systems, > >> >> > Solaris in particular. So instead I'd propose following patch: > >> >> > > >> >> > @@ -441,7 +441,7 @@ > >> >> > � � � if [ -f $PIDFILE ] > >> >> > � � � then > >> >> > � � � � � PID=`head -n 1 $PIDFILE` > >> >> > - � � � � kill -s 0 $PID >/dev/null 2>&1 > >> >> > && fuser > > $OCF_RESKEY_pgdata > >> >> > 2>&1 | grep $PID >/dev/null 2>&1 > >> >> > + � � � � runasowner "kill -s 0 $PID > >> >> > >/dev/null 2>&1" > >> >> > � � � � � return $? > >> >> > � � � fi > >> >> > > >> >> > It would guarantee that process with that PID is up and owned by > >> >> > pg_dba user. I believe that here we can assume that that process is > >> >> > PosgressSQL database. Further check with running sql monitor will make > >> >> > it sure. > >> >> > > >> >> > The complete patch is attached. > >> >> > >> >> This looks good enough to me. If nobody other objects, I'd apply > >> >> this patch. > >> > > >> > Dejan, you asked it yourself: > >> > why do we need to kill $PID at all, anyways? > >> > Why not directly do the sql monitoring? > >> > >> It's possible to configure pgsql RA to monitor database over Virtual > >> IP, not over local UNIX socket. In this case if there were no first > >> status check for process PID (actually that pgsql_status function) > >> monitor function would succeed on all cluster nodes that were able to > >> connect to Virtual IP. That would break a whole cluster. So doing > >> status check before SQL monitoring guarantees that PostgreSQL is > >> running locally on a node where ra runs. > >> > >> > > >> > -- > >> > : Lars Ellenberg > >> > : LINBIT | Your Way to High Availability > >> > : DRBD/HA support and consulting http://www.linbit.com > >> > > >> > DRBD� and LINBIT� are registered trademarks of LINBIT, > >> > Austria. > >> > _______________________________________________________ > >> > Linux-HA-Dev: [email protected] > >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > >> > Home Page: http://linux-ha.org/ > >> > > >> > >> > >> > >> -- > >> Serge Dubrouski. > >> _______________________________________________________ > >> Linux-HA-Dev: [email protected] > >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > >> Home Page: http://linux-ha.org/ > >> > > > > _______________________________________________________ > > Linux-HA-Dev: [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > Home Page: http://linux-ha.org/ > > > > > > -- > Serge Dubrouski. > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ > _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
