setproctitle()

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: setproctitle()
Date: 2000-05-23 22:48:02
Message-ID: 200005232248.SAA20379@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Seems BSD/OS 4.01 has setproctitle() in libutil.o, even though there is
no include file nor manual page.

I checked the library source, and it is a very light-weight function.
It grabs an argv global from crt0.o, and changes the ps args. Very fast.

I now see that systems that use setproctitle() seem totally broken for
updates. The code says:

setproctitle("%s %s %s %s %s", execname, hostname, username, db...

#define PS_SET_STATUS(status) \
do { strcpy(Ps_status_buffer, (status)); } while (0)

Of course, there is no linkage between Ps_status_buffer and the
setproctitle args here, so it is no-op. The fix is to move
setproctitle() down into PS_SET_STATUS().

Seems this is Marc's new code:

date: 2000/05/12 13:58:24; author: scrappy; state: Exp; lines: +2 -1

Add two checks ... one for setproctitle and one for -lutil ...

Don't do anything with them at this time, but am working on that ...

I know we have been talking about using setproctitle() in all cases that
support it, and in fact we now do that. What we don't do is use
setproctitle() to update the status for each query.

So it seems that he has enabled it on my platform. Do people want
setproctitle() to update for every query for 7.01? I have seen FreeBSD
and BSDI implementations, and they are both light-weight.

Comments?

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2000-05-23 22:55:23 MySQL now supports transactions ...
Previous Message The Hermit Hacker 2000-05-23 22:36:52 Re: New Lists ...