469,576 Members | 1,721 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,576 developers. It's quick & easy.

PGSTATBUFF: Warning - receive buffer full

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
2 1750
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
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.

Similar topics

2 posts views Thread by William Stacey | last post: by
reply views Thread by ?lafur Helgi R?gnvaldsson | last post: by
1 post views Thread by Saso Zagoranski | last post: by
reply views Thread by Willis | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.