From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: LISTEN vs. two-phase commit |
Date: | 2008-03-11 14:37:53 |
Message-ID: | 19276.1205246273@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-03-11 14:41:57 | Re: [PATCHES] Fix for large file support (nonsegment mode support) |
Previous Message | Larry Rosenman | 2008-03-11 13:59:58 | Re: [PATCHES] Fix for large file support (nonsegment mode support) |