Re: LISTEN vs. two-phase commit

"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