> > 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 real world it > might not be (Mac OS X is an example of a platform that I > don't think has all three SysV IPC parts).
Ok. Yikes. Any suggestions for alternative methods= > 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 backend pid as the message id. Eh. One message queue per cluster, that is. > 3. This doesn't seem to really address my objection of not > being able to trigger the signal manually. Certainly kill(1) > is not smart enough, and even if we invent a pg_kill program, > how will it know which message queue to stick the extended > signal in? We have already invented pg_kill. It's "pg_ctl kill". > The IDs of the message queues would not be > readily available to anyone without access to the cluster's > shared memory, much less the mapping between message queue ID > and process PID. ftok() on pg_control or something in the clusters data directory was my intention. (Again, just one message queue) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
