Re: LISTEN/NOTIFY enhancement: Portable signal handling?
От | Sean Chittenden |
---|---|
Тема | Re: LISTEN/NOTIFY enhancement: Portable signal handling? |
Дата | |
Msg-id | 8A7EF364-583A-11D9-A9FF-000A95C705DC@chittenden.org обсуждение исходный текст |
Ответ на | Re: LISTEN/NOTIFY enhancement: Portable signal handling? ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
Список | pgsql-hackers |
>> NOTIFY 'relname' a_expr; > This would be great to have...at least I think this is what you are > driving at: (adding a noiseword for readability) > > LISTEN system_messages; > NOTIFY system_messages MESSAGE logoff; > NOTIFY request_unlock MESSAGE 12345; <-- for use with user locks! Hrm... the userlock module may work for what I'm after, but the module is GPL'ed, which is something I don't want to rely on. I wanted to have a backend process essentially act as a long running client that would act on notify messages to dispatch work. I was hoping to accomplish something like, "LISTEN REGISTER event_name; LISTEN * BLOCK WITH TIMEOUT = 30;" which would only listen to events that you've registered to listen to, but would only deliver messages when you explicitly were going to block waiting for message delivery (ie, LISTEN BLOCK). I'll settle for getting just message passing via NOTIFY/LISTEN to work and will revisit extending things further once I have this bit done. -sc -- Sean Chittenden
В списке pgsql-hackers по дате отправления: