SEO

> I have simplified the code according to the discussion. Now
> there is no pipe or signaling threads, process access shared
> memory directly to pass signals.
> Seems everything works fine except pg_ctl. I now have two
> choices to fix it:
>
> (1) Record Shared memory name (it is already there) and the
> offset of signaling shared memory in postmaster.pid; So the
> pg_ctl program can access the shared memory (since it has
> write down the signal number there) and SetEvent target process;

Why not just use the pid in teh name, and have one segment per backend?
Remember on Win32 having a couple of hundred shared memory segments is
not a problem. (I assume you are creating these using MapViewOfFile()
etc, and not using the shmget() emulators)

Then if I want to kill pid 1234 I just do:
mtx = OpenMutex(..,"pqsignalmtx1234");
WaitForSingleObject(mtx);
m = OpenFileMapping(...,"pqsignal1234");
v = MapViewOfFile();
-- write signal number --
UnmapViewOfFile(v);
CloseHandle(m);
e = OpenEvent(..,"pqsignalevt1234");
SetEvent(e);
CloseHandle(e);
ReleaseMutex(mtx);
CloseHandle(mtx);

(pseudo-code. You'll need to look for deadlocks in the event processor,
but it should be fairly easy to write code that won't deadlock)



>
> (2) Postmaster will startup a thread monitoring messages,
> pg_ctl simulate "kill" by sending postmaster a message
> <target_pid, signum>, then postmaster will forward this
> "signum" to "target_pid";

I don't like that. If the postmaster dies, how will you signal the
remaining backends? The signal processing has to take place in the
actual backend affected, and only there. But that should be no problem
with the solution I outlined above.

This way you'll also be able to pg_kill a process without knowing where
the postmaster.pid file is, which at least I would expect. Needing to
specify the full data path just to run pg_kill is not good.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

"Magnus Hagander" <mha@sollentuna.net> writes:
> Why not just use the pid in teh name, and have one segment per backend?

Being used only for signals you mean? That might work.

I dislike fooling around with the contents of postmaster.pid, as that
will inject platform-specific code into places where there is none now.
If that's what the patch ends up requiring, I for one will vote to leave
things as they are now.

>> (2) Postmaster will startup a thread monitoring messages,
>> pg_ctl simulate "kill" by sending postmaster a message
>> <target_pid, signum>, then postmaster will forward this
>> "signum" to "target_pid";

> I don't like that. If the postmaster dies, how will you signal the
> remaining backends?

Agreed, this seems pretty fragile ... and one thing you want from signal
processing is robustness. It needs to be possible to signal a given
process without any support from any other.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings