Re: LISTEN vs. two-phase commit

Tom Lane wrote:
> "Heikki Linnakangas" <heikki@enterprisedb.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.

>> There is one slightly interesting use case 
>> though: if the client application ignores self-notifies, it would ignore 
>> the NOTIFYs of the prepared transactions it commits, even though they 
>> originally ran in another backend. It's worth mentioning in the docs, 
>> but I would leave it as it is for now.
> 
> Yeah, the original reason for sending the PID was exactly so that the
> client could tell self-notifies apart from remote ones.  The question
> is, what the heck is a "self-notify" in the 2PC context?

I don't know. Perhaps we should just always report -1 as the PID with 
2PC? Seems like the safest option.

Often you do use the same connection to send both PREPARE TRANSACTION 
and COMMIT PREPARED, and do nothing in-between. If you use it like that, 
then the 2PC is not any different from a normal commit from 
LISTEN/NOTIFY point of view, and we could interpret self-notify as one 
that came from your own backend.

This is all very hand-wavy of course, as we don't know of any real 
application that uses LISTEN/NOTIFY with 2PC...

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com