Re: PGSTATBUFF: Warning - receive buffer full - Mailing list pgsql-general

From Jan Wieck
Subject Re: PGSTATBUFF: Warning - receive buffer full
Date
Msg-id 40A97DB0.3070500@Yahoo.com
Whole thread Raw
In response to Re: PGSTATBUFF: Warning - receive buffer full  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:

> Robert Treat <xzilla@users.sourceforge.net> writes:
>> May 12 15:15:51 gnvdb01 postgres[801]: [75] LOG:  PGSTATBUFF: Warning -
>> receive buffer full
>
>> given the archives seem to have no mention of this error, I'm just
>> curious as to what it actually means if its something I should be
>> concerned about.. ie. will it lead to problems somewhere down the line.
>
> It means the pgstats subprocess fell far enough behind to drop some
> data.  This is the designed behavior under heavy load, so it doesn't
> bother me particularly.  I think the worst known consequence is bogus
> entries in pg_stat_activity (eg, if the stats process missed a
> backend-exiting message, it would continue to show that backend as
> present in pg_stat_activity, until some other backend starts in the
> same BackendId slot).

Which is the "best possible" behaviour we came up with in the case too
much data was generated way back when the stats collector was written. I
remember that we discussed the (dis-)advantages of having the backends
waiting or not waiting for statistics collection. The decision was made
to never wait for them and the resulting design was to send on a lossy
UDP socket, with one process receiving as fast as possible and
attempting to detect and reporting losses while another counts and
stores the stuff.

I still stand behind this concept. If you hit these limits, it's likely
you suffer at other ends a lot more and shouldn't worry about lost stats
too much, aren't you?


Jan

>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings


--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-general by date:

Previous
From: Duane Lee - EGOVX
Date:
Subject: Hardware Platform
Next
From: Scott Ribe
Date:
Subject: Re: I want to use postresql for this app, but...