> > Also, are these items completed? How about our cancel query key? I
> > think it is random/secure enough for our purposes. Can you make the
> > changes, or do you need changes from me?
>
> After pulling down the current cvs sources and taking a quick look
> around, I guess nothing has happened on this front whilst I wasn't
> paying attention. There is code in postmaster.c to compute a cancel
> key for each newly-spawned backend, but nothing ever gets done with it.
>
> What we still need to do, I think:
>
> 1. Define the client-to-postmaster message that requests a cancel.
I was totally lost on where to implement this. I looked and could not
find the proper place for it. I am sure you will be able to figure it
out.
> 2. Implement code in postmaster.c that receives this message and sends
> a signal to the appropriate backend. (What signal did you want to use?
> I assume SIGURG would be a bad idea, probably SIGUSR1 or 2...)
Sure, either of these, and replace the current use of SIGURG with the
new one.
>
> 3. Modify postgres.c to treat that signal not SIGURG as requesting a
> cancel; no real change in how the signal is handled, only what signal
> number it is.
Yep, just search/replace. I recommend mkid, (see FAQ_DEV). Very nice
for this type of thing, though overkill in this case.
> 4. However, we can and probably should rip out *all* OOB-related code
> in the backend. It's dead code and probably always will be, given the
> portability issues.
Yes, other interfaces probably don't support OOB. That was the most
convincing argument to scrap OOB.
>
> 5. Define an additional protocol message that tells the client what the
> secret cancel key is; have postgres.c send this at some appropriate
> point during startup.
Yes.
>
> 6. Modify libpq to save the cancel key and issue cancels via the message
> to the postmaster instead of OOB.
Yep, and you said you want to save the PID too, which makes sense.
Postmaster has to spin through its structure, find the proper pid, and
check against the secret key. If someone sends a bogus request, please
dump something to the postmaster log file. Will be helpful for
debugging.
>
> 7. Document these protocol changes. (Do we still call this protocol
> 2.0, or should we go to 3.0?? Officially 2.0 isn't out yet, so I think
> we can just change it.)
Still 2.0. No one is using it in production yet, I hope.
>
> Anything I've missed? How much of this do you feel like doing?
> I'm happy to do 5,6,7, but am less sure of my competence for 1-4.
I am confused by 1-4 myself, especially the place in the protocol to
pass the secret key to the backend, and the place to receive the
protocol change. I can help with the postmaster/backend logic flow, but
I don't have a concept of the various protocol packets that get sent
using various authentication methods.
--
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)
