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.
2010/11/4 <[email protected]>:
> Hi All,
>
> We discovered a phenomenon to fail in monitor processing from the delay of
> the fuser command of pgsql.
>
> When the output to the disk is frequent, the case which is behind with a
> fuser command occurs.
> * When we performed the output to the mountpoint of NFS in large quantities
> in our environment, it
> occurred.
>
> The fuser command searches all entries in a proc directory.
> On this account a delay occurs when we output large quantities.
>
> We made the patch which referred to a proc directory directly without using
> the fuser command.
>
> This patch works in the output of a large quantity of disks for light
> movement in comparison with the
> fuser command definitely.
>
> Please confirm a patch.
> And please apply this patch to developer-version.
>
> Best Regards,
> Hideo Yamauchi.
>
> _______________________________________________________
> Linux-HA-Dev: [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
>
--
Serge Dubrouski.
pgsql_no_fuser
Description: Binary data
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
