Thread: ps buffer is incorrectly padded on the (latest) OS X

ps buffer is incorrectly padded on the (latest) OS X

From
Alexey Klyukin
Date:
Hi,

I always wondered why ps ax|grep postgres shows several extra blank lines
after the process name, i.e.
 972   ??  Ss     0:00.69 postgres: writer process






973   ??  Ss     0:00.51 postgres: wal writer process

(I put newlines instead of spaces there). By looking into the code I've found
this part of set_ps_display:

#ifdef PS_USE_CLOBBER_ARGV/* pad unused memory; need only clobber remainder of old status string */if (last_status_len
>ps_buffer_cur_len)    MemSet(ps_buffer + ps_buffer_cur_len, PS_PADDING,           last_status_len -
ps_buffer_cur_len);last_status_len= ps_buffer_cur_len; 
#endif   /* PS_USE_CLOBBER_ARGV */

PS_PADDING padding on __darwin__ is set to ' '. Apparently this doesn't work
correctly with OS X 10.6. After I changed the define to use '\0' on darwin
extra blank likes (actually consisting of hundreds of spaces without a line
break) disappeared. The one-liner change follows:

===
diff --git a/src/backend/utils/misc/ps_status.c b/src/backend/utils/misc/ps_status.c
index f27a52f..c2ddf33 100644
--- a/src/backend/utils/misc/ps_status.c
+++ b/src/backend/utils/misc/ps_status.c
@@ -76,7 +76,7 @@ bool        update_process_title = true;/* Different systems want the buffer padded differently */
-#if defined(_AIX) || defined(__linux__) || defined(__svr4__)
+#if defined(_AIX) || defined(__linux__) || defined(__svr4__) || defined(__darwin__)#define PS_PADDING '\0'#else#define
PS_PADDING' ' 
===

I don't have different OS X versions to test, so I'm not sure whether 10.5 or
below are also affected. Also, the patch should specifically check for 10.6,
though I don't know how to distinguish between different OS X versions in
postgres sources (any suggestions?).

Regards,
--
Alexey Klyukin                    http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc



Re: ps buffer is incorrectly padded on the (latest) OS X

From
Tom Lane
Date:
Alexey Klyukin <alexk@commandprompt.com> writes:
> I always wondered why ps ax|grep postgres shows several extra blank lines
> after the process name, i.e.

AFAIR it's always done that on OSX.  I thought we'd tried the '\0'
padding way back when and it didn't work nicely, but maybe Apple fixed
that.
        regards, tom lane


Re: ps buffer is incorrectly padded on the (latest) OS X

From
Tom Lane
Date:
I wrote:
> Alexey Klyukin <alexk@commandprompt.com> writes:
>> I always wondered why ps ax|grep postgres shows several extra blank lines
>> after the process name, i.e.

> AFAIR it's always done that on OSX.  I thought we'd tried the '\0'
> padding way back when and it didn't work nicely, but maybe Apple fixed
> that.

I tried this on a PPC Mac running 10.4.11, which is the oldest Mac OS
I have handy at the moment.  It worked fine.  The existing coding in
ps_status.c dates from late 2001, which means that it was first tested
against OS X 10.1, and most likely we have not rechecked the question
of what PS_PADDING value to use since then.  My guess is that Apple
must have changed this in OS X 10.2 or 10.3, because the userland
Unix utilities were pretty well settled after that.

So I think we could definitely apply this change to HEAD/9.0, and I'm
strongly tempted to back-patch further than that.  Does anybody think
that any pre-10.4 OS X versions are still in use, or would be likely
to receive Postgres updates if they do exist?
        regards, tom lane


Re: ps buffer is incorrectly padded on the (latest) OS X

From
Robert Haas
Date:
On Fri, Sep 3, 2010 at 7:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Alexey Klyukin <alexk@commandprompt.com> writes:
>>> I always wondered why ps ax|grep postgres shows several extra blank lines
>>> after the process name, i.e.
>
>> AFAIR it's always done that on OSX.  I thought we'd tried the '\0'
>> padding way back when and it didn't work nicely, but maybe Apple fixed
>> that.
>
> I tried this on a PPC Mac running 10.4.11, which is the oldest Mac OS
> I have handy at the moment.  It worked fine.  The existing coding in
> ps_status.c dates from late 2001, which means that it was first tested
> against OS X 10.1, and most likely we have not rechecked the question
> of what PS_PADDING value to use since then.  My guess is that Apple
> must have changed this in OS X 10.2 or 10.3, because the userland
> Unix utilities were pretty well settled after that.
>
> So I think we could definitely apply this change to HEAD/9.0, and I'm
> strongly tempted to back-patch further than that.  Does anybody think
> that any pre-10.4 OS X versions are still in use, or would be likely
> to receive Postgres updates if they do exist?

I don't think we should back-patch this.  It's not a bug fix, just a
convenience.  We already have enough trouble with people not believing
that our minor releases are safe, and having non-critical stuff in the
release notes does not help our case.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


Re: ps buffer is incorrectly padded on the (latest) OS X

From
Tom Lane
Date:
I wrote:
> I tried this on a PPC Mac running 10.4.11, which is the oldest Mac OS
> I have handy at the moment.  It worked fine.  The existing coding in
> ps_status.c dates from late 2001, which means that it was first tested
> against OS X 10.1, and most likely we have not rechecked the question
> of what PS_PADDING value to use since then.  My guess is that Apple
> must have changed this in OS X 10.2 or 10.3, because the userland
> Unix utilities were pretty well settled after that.

Just for the archives' sake: I dug through the OS X source code archives
and confirmed that this behavior changed at 10.3: compare getproclline
in 10.2.8
http://www.opensource.apple.com/source/adv_cmds/adv_cmds-46/ps.tproj/print.c
vs 10.3
http://www.opensource.apple.com/source/adv_cmds/adv_cmds-63/ps.tproj/print.c

So we don't need a version check unless you're worried about somebody
trying to run Postgres 9.x on OS X 10.2 (which was retired in 2003).
        regards, tom lane


Re: ps buffer is incorrectly padded on the (latest) OS X

From
Heikki Linnakangas
Date:
On 04/09/10 22:41, Tom Lane wrote:
> I wrote:
>> I tried this on a PPC Mac running 10.4.11, which is the oldest Mac OS
>> I have handy at the moment.  It worked fine.  The existing coding in
>> ps_status.c dates from late 2001, which means that it was first tested
>> against OS X 10.1, and most likely we have not rechecked the question
>> of what PS_PADDING value to use since then.  My guess is that Apple
>> must have changed this in OS X 10.2 or 10.3, because the userland
>> Unix utilities were pretty well settled after that.
>
> Just for the archives' sake: I dug through the OS X source code archives
> and confirmed that this behavior changed at 10.3: compare getproclline
> in 10.2.8
> http://www.opensource.apple.com/source/adv_cmds/adv_cmds-46/ps.tproj/print.c
> vs 10.3
> http://www.opensource.apple.com/source/adv_cmds/adv_cmds-63/ps.tproj/print.c
>
> So we don't need a version check unless you're worried about somebody
> trying to run Postgres 9.x on OS X 10.2 (which was retired in 2003).

What happens if someone does? Crash, or just wonky ps output? If it's 
the latter, seems safe to backpatch.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


Re: ps buffer is incorrectly padded on the (latest) OS X

From
Tom Lane
Date:
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 04/09/10 22:41, Tom Lane wrote:
>> So we don't need a version check unless you're worried about somebody
>> trying to run Postgres 9.x on OS X 10.2 (which was retired in 2003).

> What happens if someone does? Crash, or just wonky ps output? If it's 
> the latter, seems safe to backpatch.

Wonky ps output.  I don't recall exactly how wonky, but back in the day
it looked better blank-padded.
        regards, tom lane