Re: PGSTATBUFF: Warning - receive buffer full

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: PGSTATBUFF: Warning - receive buffer full
Date: 2004-05-18 03:06:24
Message-ID: 40A97DB0.3070500@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:

> Robert Treat <xzilla(at)users(dot)sourceforge(dot)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(at)Yahoo(dot)com #

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Ribe 2004-05-18 03:39:41 Re: I want to use postresql for this app, but...
Previous Message Duane Lee - EGOVX 2004-05-17 23:08:34 Hardware Platform