Re: View pg_stat_activity slow to get up to date

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: View pg_stat_activity slow to get up to date
Дата
Msg-id 418FB369.302@Yahoo.com
обсуждение исходный текст
Ответ на View pg_stat_activity slow to get up to date  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Ответы Re: View pg_stat_activity slow to get up to date  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Список pgsql-hackers
On 11/8/2004 12:03 PM, D'Arcy J.M. Cain wrote:

> I checked the FAQ and docs but haven't found anything definitive.  This
> is my SQL test script:
> 
> SELECT pg_backend_pid();
> SELECT * FROM pg_stat_activity order by procpid;
> 
> When I run psql reading that I find that my backend procpid is not in
> the list.  I know that I can see it if I can introduce a little sleep (1
> second) between the connection and the reading of pg_stat_activity.

That is because the way your backend gets the information from the 
pgstat daemon process is by reading a file, which is at maximum written 
by that process every 500 msec. You will hardly ever see your own query.

> 
> My question is this.  Is there a more reliable way to see if a
> particular backend is still alive?  I am trying to do a locking system
> and this is necessary to make it work.  I think that in actual sessions
> I will be OK but my unit test fails most of the time because of this.

All these statistics are unreliable "by design", as explained numerous 
times on this list. In short, a backend should never be slowed down 
because the pgstat process can't swallow the stats fast enough. That is 
the reason for using UDP in the first place. So the kernel is allowed to 
drop stats packets, but not to block a backend.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Reini Urban
Дата:
Сообщение: Re: latest cygwin build failure
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [pgsql-www] pg_autovacuum is nice ... but ...