Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
