ps buffer is incorrectly padded on the (latest) OS X
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
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
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
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
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
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.cSo 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
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