From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | James Stuart <slim2k(at)privatejuris(dot)org> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Can two-phase commit support LISTEN, UNLISTEN, and NOTIFY? |
Date: | 2023-09-16 23:03:05 |
Message-ID: | 3978033.1694905385@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
James Stuart <slim2k(at)privatejuris(dot)org> writes:
> Can you please clarify, is lack of support for "LISTEN, UNLISTEN, and
> NOTIFY" with two-phase commits an architecture limitation or is this
> lacking implementation?
The point of LISTEN and UNLISTEN is to change the listening state of
the current session, so it's hard to see how it'd make sense to
decouple them into a prepared transaction that might get committed by
a different session. That'd end up with that other session changing
listen state (barring some really messy mechanism for propagating
the change back to the original session, assuming it still exists);
which seems surprising and probably not very useful.
I suppose you could argue that NOTIFY is a fire-and-forget operation
that could be postponed into a prepared transaction without making
a semantic mess. But even then, it's not very clear whether the
message ought to carry the PID of the original session or the
committing session. The original session would make more sense,
were it not that that might not exist anymore (and indeed its PID
could now be in use by some unrelated process).
Another problem, which perhaps is an implementation detail but
is real nonetheless, is that the current NOTIFY logic goes out
of its way to ensure that NOTIFY cannot cause a post-commit failure.
It does that by pushing the pending NOTIFY message(s) into the shared
queue before we reach the point of atomic commit. If we run out of
space in the notify queue we can still fail the current transaction.
This approach is dependent on the assumption that it won't be very
long from pushing the messages into the queue to actual commit, else
we run the risk of clogging the queue. So we couldn't perform that
step during PREPARE, and then there's a problem that we've created a
way for COMMIT PREPARED to fail, which ideally it should never do.
So I think there are indeed semantic issues, it's not entirely
a matter of "nobody got around to it".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Anthony Apollis | 2023-09-17 17:24:52 | Ensuring Rifferential Integrity |
Previous Message | Maciek Sakrejda | 2023-09-16 19:01:15 | Re: update from 13 to16 |