Joachim Wieland wrote:
> The example you brought up fails if
> Session 2 disregards the notifications based on the current set of
> channels that it is listening to at this point.
Right. Session 2 might not be listening at all yet.
> If I understand you
> correctly what you are suggesting is to not read uncommitted
> notifications from the queue in a reading backend or read all
> notifications (regardless of which channel it has been sent to), such
> that the backend can apply the check ("Am i listening on this
> channel?") later on.
Right.
> Note that we don't preserve notifications when the database restarts.
> But 2PC can cope with restarts. How would that fit together?
The notifications are written to the state file at prepare. They can be
recovered from there and written to the queue again at server start (see
twophase_rmgr.c).
> Also I am
> not sure how you are going to deliver notifications that happen
> between the PREPARE TRANSACTION and the COMMIT PREPARED (because you
> have only one queue pointer which you are not going to advance...) ?
Yeah, that's a problem. One uncommitted notification will block all
others too. In theory you have the same problem without 2PC, but it's OK
because you don't expect one COMMIT to take much longer to finish than
others.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
