Re: [HACKERS] memory fields from getrusage()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] memory fields from getrusage()
Дата
Msg-id 25050.1497144685@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [HACKERS] memory fields from getrusage()  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: [HACKERS] memory fields from getrusage()  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> This comment from ~1996 says:
> https://doxygen.postgresql.org/postgres_8c_source.html
>  4421      * the only stats we don't show here are for memory usage -- i can't
>  4422      * figure out how to interpret the relevant fields in the rusage struct,
>  4423      * and they change names across o/s platforms, anyway. if you can figure
>  4424      * out what the entries mean, you can somehow extract resident set size,
>  4425      * shared text size, and unshared data and stack sizes.

> .. is that really (still) the case for supported platforms?  I'm hoping that in
> 2017 one can just call getrusage() if autoconf says it's okay ??

We already do call getrusage().  The point of that comment is that the
contents of the resulting struct rusage are not very well standardized.
POSIX says only
   The <sys/resource.h> header defines the rusage structure that includes   at least the following members:
struct timeval ru_utime   user time usedstruct timeval ru_stime   system time used

(seems the same in 1997 and 2008 text).  So the existing code has already
got its neck stuck way out in terms of portability.  Maybe you could push
it further, but I bet you'll find that the situation isn't any better than
it was at the time that comment was written.

It's entirely possible that we could simplify the code some, because
I suspect that Windows is the only remaining platform that doesn't
HAVE_GETRUSAGE.  But that in itself doesn't mean we can use any more
fields than we do now.
        regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: [HACKERS] Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Make ANALYZE more selective about what is a "mostcommon value"?