Re: getpid() function

As I remember, most cases where people have recently been asking for
backend pid were related to temp tables because they were named by pid.
I don't think they are anymore. (?)

We can do two things. We can either rename it to pg_backend_pid and
move it to the statistics section in the docs, where the backend pids of
all active backends are available, or remove my code additions and see
if anyone asks for it in 7.3.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Perhaps a more relevant question is why are we cluttering the namespace
> > > with any such function at all? What's the use case for it?
>
> > It was requested because it is exposed in libpq and people need it to
> > generate unique names and stuff like that from within psql and
> > functions. Seems like a valid use for the pid.
>
> The sole reason libpq exposes it is so that you can tell a self-notify
> from an incoming notify. (ie, given you are LISTENing on a condition
> that both you and other clients send NOTIFYs for, is this particular
> message one that you sent yourself, or not? Compare the originator PID
> in the NOTIFY message to your backend_pid to find out.) I put that
> feature in back around 6.4, because it allowed some important
> optimizations in an app I had that used LISTEN/NOTIFY a lot.
>
> Since NOTIFY messages aren't even visible at the SQL level, the above is
> not a reason for making PIDs visible at the SQL level.
>
> I'm really dubious about using backend PID for the sort of purpose you
> suggest. Unique names would be *much* more safely handled with, say,
> a sequence generator. If you are not using libpq or another client
> library that can give you a backend-PID API call, then very likely you
> don't have a lot of control over the backend connection either, and
> shouldn't assume that backend PID is going to be stable for you.
> (Think about pooled connections in a webserver, etc.)
>
> Finally, the most legitimate uses of PID (like discovering a backend PID
> to send SIGINT to, when some client query is running wild) are not
> supported at all by a function that can only return your own backend's
> PID, because that's seldom the PID you need to know. The
> pg_stat_activity view handles this much better.
>
> So I'm still unconvinced that we need or want this ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
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