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 #
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 |