Skip site navigation (1) Skip section navigation (2)

Re: notify with payload (pgkill, notify)

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: notify with payload (pgkill, notify)
Date: 2008-04-02 19:41:10
Message-ID: 47F3E156.6070206@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

James Mansion wrote:
> Is the intent to replace most uses of (pg)kill with a general
> purpose messaging system between the processes, or
> (just) to address notify per se?
>
> (Presumably with 'fire-and-forget' and also rpc
> semantics?  And pub-sub? And some sort of
> write to an fd protected by an atomic flag to
> elide multiple writes when the process hasn't woken
> and acknowledged the ATTN yet?)
>
> If pgkill is not used for signalling, could this reduce the reliance 
> on signals
> (except for trying to kill off processes) to the point
> where ot becomes much less scary to link to libraries
> that use signals themselves and/or threaded runtimes?



My intention is to revamp the listen/notify system, pure and simple.

If you have an alternative suggestion them you need to make it now.

We are not intending to use FDs for message passing. They will be stored 
in shared memory. See previous discussions for details:

http://groups.google.com/group/pgsql.hackers/browse_frm/thread/e63a5ac43e2508ce/e0892fb3316cc327?hl=en&lnk=gst&q=notify+payload#e0892fb3316cc327
http://groups.google.com/group/pgsql.hackers/browse_frm/thread/6a59675a3e11bedc/87e0ce6dd6cce6a6?hl=en&lnk=gst&q=notification+payload#87e0ce6dd6cce6a6


cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-04-02 19:43:48
Subject: Re: Patch queue -> wiki (was varadic patch)
Previous:From: Andrew SullivanDate: 2008-04-02 19:35:34
Subject: Re: Can Postgres 8.x start if some disks containing tablespaces are not mounted?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group