On Thu, Nov 04, 2010 at 10:51:49AM +0100, Dejan Muhamedagic wrote: > Hi, > > On Thu, Nov 04, 2010 at 03:12:06PM +0900, [email protected] wrote: > > 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. > > Isn't all that superfluous? If there's a pid in the pidfile and > the process is running, can that process be anything else?
Sure. Original process died, pidfile may be stale, pid has been recycled since. Pid space wrap around may happen much sooner than you'd think, sometimes. It's still possible that the recycled pid now happens to have its cwd where we expected the original pid, but less likely. The actual monitor action does a sql level operation for that reason. So yes, we probably could do away with the pid check, it does not serve any further purpose if we directly go for the sql level check (but maybe it fails faster...) -- : 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/
