Re: Configuration of statistical views

Tom Lane wrote:
> Jan Wieck <JanWieck(at)yahoo(dot)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 missing stop. Except a PID
wraparound causes a fix someday. Maybe it should
periodically (every 10 minutes or 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(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com