Re: PGSTATBUFF: Warning - receive buffer full
От | Jan Wieck |
---|---|
Тема | Re: PGSTATBUFF: Warning - receive buffer full |
Дата | |
Msg-id | 40A97DB0.3070500@Yahoo.com обсуждение исходный текст |
Ответ на | Re: PGSTATBUFF: Warning - receive buffer full (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
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 #
В списке pgsql-general по дате отправления: