Tom Lane wrote:
> Jan Wieck <JanWieck@yahoo.com> writes:
> >> backend start/stop events probably need to be reported whenever the
> >> postmaster variable is set, even if all the USERSET variables are off.
>
> > I don't consider backend start/stop messages to be critical,
> > although we get some complaints already about connection
> > slowness - well, this is somewhere in the microseconds. And
> > it'd be a little messy because the start message is sent by
> > the backend while the stop message is sent by the postmaster.
> > So where exactly to put it?
>
> This is exactly why I think they should be sent unconditionally.
> It doesn't matter if a particular backend turns its reporting on and
> off while it runs (I hope), but I'd think the stats collector would
> get confused if it saw, say, a start and no stop message for a
> particular backend.
>
> OTOH, given that we need to treat the transmission channel as
> unreliable, it would be a bad idea anyway if the stats collector got
> seriously confused by not seeing the start or the stop message.
Hmmm - that's a good point. Right now, the collector is totally lax on all of that. Missing start
packet - no problem, we create the backend slot on the fly. Missing stats packet - well, the counters aren't 100%
correct, so be it. But OTOH it causes him to remember the dead backend for postmaster lifetime in case of a
missingstop. Except a PID wraparound causes a fix someday. Maybe it should periodically (every 10
minutesor even longer) check with a zero-kill if all the backends it knows about are really alive.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
