From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: LISTEN vs. two-phase commit |
Date: | 2008-03-11 15:17:23 |
Message-ID: | 20564.1205248643@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>>> To be honest, I didn't realize the receiver gets to know the PID of the
>>> sending process, but clearly it does. It seems mostly indifferent to me;
>>> it's not guaranteed that the PID is valid by the time the client
>>> application sees it anyway.
>>
>> Well, with the current definition it is; but that seems like a point
>> against trying to send the original PID.
> There's a small window between backend A committing and sending a
> NOTIFY, and the time client B receives the notification from backend B
> through the connection and reacts to it.
Sorry, I was unclear: the case that's of interest is telling
self-notifies apart from others. For this purpose, your own backend's
PID *is* sufficiently stable, because you're still connected to it
when the notify is sent to you.
> This is all very hand-wavy of course, as we don't know of any real
> application that uses LISTEN/NOTIFY with 2PC...
Yeah. I'm inclined to leave that alone (but document it) until/unless
someone complains. Without a real use-case to look at, it's a bit hard
to be sure what's a useful behavior.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-03-11 15:21:04 | Re: LISTEN vs. two-phase commit |
Previous Message | Cliff Nieuwenhuis | 2008-03-11 15:10:15 | encoding problems |