Skip site navigation (1) Skip section navigation (2)

Re: Configuration of statistical views

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Configuration of statistical views
Date: 2001-06-29 18:44:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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



# 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 address at

In response to

pgsql-hackers by date

Next:From: Alex PilosovDate: 2001-06-29 18:46:40
Subject: functions returning sets
Previous:From: Jan WieckDate: 2001-06-29 18:36:13
Subject: Re: Configuration of statistical views

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group