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