Tom Lane wrote:
Does it make any sense to allow LISTEN or UNLISTEN in a prepared
transaction?
It's certainly not sensical for these actions to affect the backend that
actually executes the COMMIT PREPARED, in the sense of creating or
destroying pg_listener entries for it. But how can we say
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
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
Heikki Linnakangas [EMAIL PROTECTED] writes:
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
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
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.
Sorry, I was unclear: the case that's of interest is
Does it make any sense to allow LISTEN or UNLISTEN in a prepared
transaction?
It's certainly not sensical for these actions to affect the backend that
actually executes the COMMIT PREPARED, in the sense of creating or
destroying pg_listener entries for it. But how can we say that they
should
Tom Lane wrote:
Does it make any sense to allow LISTEN or UNLISTEN in a prepared
transaction?
...
Comments?
Assuming I understand your question - I don't think of LISTEN or
UNLISTEN as being valuable from a transaction perspective. It's possible
I'm missing something - but I think the
Mark Mielke [EMAIL PROTECTED] writes:
... I think the transaction overhead, and
attempts to re-use PostgreSQL tables to implement LISTEN/NOTIFY to be
clever but mis-guided.
Oh, I don't disagree with you. As I already mentioned, they desperately
need to be rewritten. However, given that
Tom Lane wrote:
Mark Mielke [EMAIL PROTECTED] writes:
... I think the transaction overhead, and
attempts to re-use PostgreSQL tables to implement LISTEN/NOTIFY to be
clever but mis-guided.
Oh, I don't disagree with you. As I already mentioned, they desperately
need to be rewritten.
