Thread: Some items for the TODO list
Things I'd like to see get in there before 6.4:
1. On HPUX, the new no-exec method of starting the backend means that
all the backends claim to be "postmaster"; there's no way to tell 'em
apart via ps(1). There is some code in postgres.c that tries to update
the process title information by tweaking the original argv[] array, but
that just plain doesn't work under HPUX, nor under quite a few other
Unix variants. I'm finding out that not being able to tell which
process is which is a real pain in the neck; I don't think it will be
acceptable for production use. I think we are going to have to bite the
bullet and borrow the process-title-setting code from sendmail --- I
know it's ugly, but it *works* on many many Unixes.
2. I'm starting to get annoyed by the inability to "unlisten" from
a particular relation. Is there a reason that there is not an UNLISTEN
command? (Like maybe it's not in ANSI SQL?) Or is it just something
that never got to the top of the to-do queue? I see that the low-level
code for a backend to unlisten itself is in there, but there's no way
for the frontend to command it to happen.
If no one else feels like working on these, maybe I will. I could use
some pointers for #2 though ... what needs to be done to add a new SQL
statement?
regards, tom lane
Tom Lane wrote: > > Things I'd like to see get in there before 6.4: > > 1. On HPUX, the new no-exec method of starting the backend means that > all the backends claim to be "postmaster"; there's no way to tell 'em > apart via ps(1). There is some code in postgres.c that tries to update > the process title information by tweaking the original argv[] array, but > that just plain doesn't work under HPUX, nor under quite a few other > Unix variants. I'm finding out that not being able to tell which > process is which is a real pain in the neck; I don't think it will be > acceptable for production use. I think we are going to have to bite the > bullet and borrow the process-title-setting code from sendmail --- I > know it's ugly, but it *works* on many many Unixes. One way to tell them apart is to see which of them is the parent of the rest. Not as nice as being able to set the title, but it might be a serviceable workaround in some cases. Ocie
> Is there a reason that there is not an UNLISTEN
> command? (Like maybe it's not in ANSI SQL?)
> If no one else feels like working on these, maybe I will. I could use
> some pointers for #2 though ... what needs to be done to add a new SQL
> statement?
I'll add the new statement if you can get the backend to do something
with it. Usually, there is a parse tree structure corresponding to the
command, with any parameters included in it. In this case, the
"unlisten" block should probably look like the "listen" block, since
both probably have similar arguments.
Let me know if you have time to work on it...
- Tom
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>> Is there a reason that there is not an UNLISTEN
>> command? (Like maybe it's not in ANSI SQL?)
> I'll add the new statement if you can get the backend to do something
> with it.
Doing something with it is trivial: duplicate the LISTEN code and then
change the call to Async_Listen to Async_Unlisten. (Async_Unlisten
already exists in src/backend/commands/async.c, though for some reason
it's not declared in src/include/commands/async.h.)
I'd do it if I knew exactly what-all has to be copied and pasted to make
a new SQL statement.
Probably the main question is whether the correct statement name is
"UNLISTEN", or whether ANSI specifies some other spelling ("STOP
LISTEN", maybe? SQL seems rather Cobol-ish in syntax choices, so I'd
kind of expect a phrase rather than a made-up word).
regards, tom lane
On Wed, 8 Jul 1998, Tom Lane wrote: > Things I'd like to see get in there before 6.4: > > 1. On HPUX, the new no-exec method of starting the backend means that > all the backends claim to be "postmaster"; there's no way to tell 'em > apart via ps(1). There is some code in postgres.c that tries to update > the process title information by tweaking the original argv[] array, but > that just plain doesn't work under HPUX, nor under quite a few other > Unix variants. I'm finding out that not being able to tell which > process is which is a real pain in the neck; I don't think it will be > acceptable for production use. I think we are going to have to bite the > bullet and borrow the process-title-setting code from sendmail --- I > know it's ugly, but it *works* on many many Unixes. Many UNIXes have a setproctitle() function, either in libc or libutil. I think a native function should be used if exists. Tom
> > On Wed, 8 Jul 1998, Tom Lane wrote: > > > Things I'd like to see get in there before 6.4: > > > > 1. On HPUX, the new no-exec method of starting the backend means that > > all the backends claim to be "postmaster"; there's no way to tell 'em > > apart via ps(1). There is some code in postgres.c that tries to update > > the process title information by tweaking the original argv[] array, but > > that just plain doesn't work under HPUX, nor under quite a few other > > Unix variants. I'm finding out that not being able to tell which > > process is which is a real pain in the neck; I don't think it will be > > acceptable for production use. I think we are going to have to bite the > > bullet and borrow the process-title-setting code from sendmail --- I > > know it's ugly, but it *works* on many many Unixes. > > Many UNIXes have a setproctitle() function, either in libc or libutil. > I think a native function should be used if exists. What is Linux doing with my changes. Do you see all the process names as postmaster? Do you see the query type displayed as part of the ps output. 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. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.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)
Tom <tom@sdf.com> writes:
> Many UNIXes have a setproctitle() function, either in libc or libutil.
> I think a native function should be used if exists.
Right, that is one of the implementation strategies found in sendmail's
code. Basically, what sendmail has is an emulation routine that
provides the setproctitle() API on systems where there is no such libc
function.
regards, tom lane
Bruce Momjian <maillist@candle.pha.pa.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.
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.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@candle.pha.pa.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)