Re: [HACKERS] Some items for the TODO list

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > We can use setproctitle/sendmail hack to change the process
> > name from postmaster to postgres, but are these sufficiently quick to
> > be run for every query to display the query type, i.e. SELECT.
>
> That's something I'm a little worried about too. The sendmail code
> offers these implementation strategies for setproctitle:
>
> #define SPT_NONE 0 /* don't use it at all */
> #define SPT_REUSEARGV 1 /* cover argv with title information */
> #define SPT_BUILTIN 2 /* use libc builtin */
> #define SPT_PSTAT 3 /* use pstat(PSTAT_SETCMD, ...) */
> #define SPT_PSSTRINGS 4 /* use PS_STRINGS->... */
> #define SPT_SYSMIPS 5 /* use sysmips() supported by NEWS-OS 6 */
> #define SPT_SCO 6 /* write kernel u. area */
> #define SPT_CHANGEARGV 7 /* write our own strings into argv[] */
>
> It looks like our existing code in postgres.c corresponds to the last
> of these (CHANGEARGV). REUSEARGV and PSSTRINGS are variants on this
> with probably not much worse performance. PSTAT is a kernel call,
> while the SCO method involves lseek and write on /dev/kmem --- at least
> two kernel calls, and likely it doesn't even work without special privs.
> BUILTIN means use libc's setproctitle, and SYSMIPS calls some other libc
> subroutine. The performance of those two methods is indeterminate, but
> probably the library routines turn around and do one of these same
> sorts of things.
>
> I'm inclined to think that another kernel call per SQL statement is
> not something to be overly worried about, but maybe you see it
> differently.
>
> Here's a thought: we could implement an additional function, say
> "fast_setproctitle", which is defined to do nothing unless the
> setproctitle implementation strategy is one we know to be fast.
> Then we'd use the regular setproctitle to set up the initial
> "postgres user database" display, and call fast_setproctitle to
> munge the display (or not) for each statement. This would have the
> additional hack value that it would be easy for a particular
> installation to override our choice about whether updating the
> process title for every statement is worthwhile.

What I think we need to do is add a configure check for setproctitle(),
and if we find it, we call it after we do the fork() to set our process
name to postgres. We also change argv, and continue changing it as a
status display.

Changing the argv pointer is cheap, and I don't know how we are going to
know if setproctitle is cheap or not, but we need to make the call if it
exists.

I don't have the function on BSDI, so someone else is going to have to
add the code.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)