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