By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,854 Members | 856 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,854 IT Pros & Developers. It's quick & easy.

PGSTATBUFF: Warning - receive buffer full

P: n/a
We got a few of these on a 7.3 server this afternoon. The server was
completed pegged on i/o activity (both physical disks, including the one
the db doesn't live on)

May 12 15:15:51 gnvdb01 postgres[801]: [75] LOG: PGSTATBUFF: Warning -
receive buffer full
May 12 15:15:52 gnvdb01 postgres[801]: [76] LOG: PGSTATBUFF: Warning -
receive buffer full
May 12 15:15:52 gnvdb01 postgres[801]: [77] LOG: PGSTATBUFF: Warning -
receive buffer full
May 12 15:15:52 gnvdb01 postgres[801]: [78] 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.
thanks in advance,

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Robert Treat <xz****@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

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

Nov 23 '05 #2

P: n/a
Tom Lane wrote:
Robert Treat <xz****@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. #
#================================================= = Ja******@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.