"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> Tom Lane wrote:
>> So I'm thinking that PREPARE TRANSACTION should throw an error if any
>> LISTEN or UNLISTEN is pending in the current transaction.
> For back-branches, I'm a bit hesitant to do that, as there might be
> applications that do LISTEN in a prepared transaction unknowingly.
I think that's a bit far-fetched...
>> BTW, another little issue I just noticed is that while 2PC can cope
>> with NOTIFY actions, the eventual notify is sent with the PID of the
>> backend that executes COMMIT PREPARED, not the one that originally
>> created the prepared transaction.
> 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 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?
regards, tom lane