Re: more signals (was: Function to kill backend)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: more signals (was: Function to kill backend)
Date: 2004-07-29 14:12:22
Message-ID: 13752.1091110342@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Magnus Hagander" <mha(at)sollentuna(dot)net> 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
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).

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.

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? 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.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2004-07-29 14:44:16 Re: Sketch of extending error handling for subtransactions in functions
Previous Message Jeroen T. Vermeulen 2004-07-29 14:10:49 Re: try/catch macros for Postgres backend