Re: [HACKERS] memory fields from getrusage() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] memory fields from getrusage()
Date
Msg-id 25050.1497144685@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] memory fields from getrusage()  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: [HACKERS] memory fields from getrusage()
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: [HACKERS] Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Make ANALYZE more selective about what is a "mostcommon value"?