PGSTATBUFF: Warning - receive buffer full

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).

regards, tom lane

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 #