>
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > Now I need help in passing the value to the font-end, and having the
> > front-end pass it to the backend for a cancel.
>
> I can work on that. Have you checked the postmaster changes into cvs?
Always. You bet.
>
> > I do not recommend passing the pid because I will store the cancel key
> > in the per-backend structure, so having the pid does not help me find
> > the backend. Might as well just scan the table to find the matching
> > cancel key, and kill that backend. We will have to store the pid in
> > the structure, but that is easy to do.
>
> I don't like this. Backend PIDs are guaranteed unique (among active
> backends); cancel keys are not guaranteed unique, unless you took some
> special measure to make them so. So you could hit the wrong backend
> if you only compare cancel keys. Since you must store the PID anyway to
> send the signal, you may as well use both to verify that you have found
> the right backend.
OK, sure, pass the pid. However, one problem is that the postmaster
does not know the pid until after it forks the backend, so if you want
to send the pid with the cancel key, you will have to send the pid from
the backend.
Also, the odds of two backends have the same cancel key, when random
returns a long() is so astonomically small, that I am willing to live
with the risk, to take the advantage of cleaner, more modular code.
Considering the problem of sending the cancel key from the backend and
not the postmaster, I dropped the pid. Remember, you have to store the
cancel key in the postmaster so sending it to the client at that point
made sense. Setting the pid after the fork is easy because there is no
communication required.
--
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)
