So what you'd basically need is a separate signal to trigger that
sort of exit, which would be easy ... if we had any spare
signal numbers.
What about multiplexing it onto an existing signal? e.g. set a
shared-mem flag saying exit after cancel then send SIGINT?
Possible, but then
Magnus Hagander [EMAIL PROTECTED] writes:
We invent something we could call extended signals that are valid only
in pgsql.
This would be handy, but I dislike your proposal of implementing it
using SysV message queues.
1. Yes, the message facility should theoretically be there if shmem and
We invent something we could call extended signals that are valid
only in pgsql.
This would be handy, but I dislike your proposal of
implementing it using SysV message queues.
1. Yes, the message facility should theoretically be there if
shmem and semaphores are there, but in the
Magnus Hagander wrote:
On top of this, we create a SystemV message queue used to pass down
extended signals (should be supported on all systems that support sysv
shared mem, and we require that..). We'd use the PID of the receiving
backend as the message type, and pass the signal number as
Magnus Hagander [EMAIL PROTECTED] writes:
2. It's even more likely that it would be there but have
unpleasantly small implementation limits. AFAICT your
proposal requires a separate message queue per backend, which
is probably going to stress any conventionally-configured
SysV facility.
Tom Lane wrote:
ftok() on pg_control or something in the clusters data directory was my
intention. (Again, just one message queue)
Doesn't work; you have to be able to cope with collisions with
previously existing queue IDs ... so in practice the queue ID has to
be treated as
2. It's even more likely that it would be there but have
unpleasantly small implementation limits. AFAICT your
proposal requires a separate message queue per backend, which
is probably going to stress any conventionally-configured
SysV facility.
Not at all. One message queue with the
