Re: [HACKERS] ps buffer is incorrectly padded on the (latest) OS X
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ps buffer is incorrectly padded on the (latest) OS X
Heikki Linnakangas heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ps buffer is incorrectly padded on the (latest) OS X
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ps buffer is incorrectly padded on the (latest) OS X
Alexey Klyukin al...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ps buffer is incorrectly padded on the (latest) OS X
I wrote: Alexey Klyukin al...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ps buffer is incorrectly padded on the (latest) OS X
On Fri, Sep 3, 2010 at 7:09 PM, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: Alexey Klyukin al...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
