Re: Listen / Notify - what to do when the queue is full

Florian G. Pflug wrote:
> Heikki Linnakangas wrote:
>> At a quick glance, it doesn't seem hard to support 2PC. Messages should
>> be put to the queue at prepare, as just before normal commit, but the
>> backends won't see them until they see that the XID has committed.
>
> Yeah, but if the server is restarted after the PREPARE but before the
> COMMIT, the notification will be lost, since all notification queue
> entries are lost upon restart with the slru design, no?

That's why they're stored in the 2PC state file in pg_twophase. See
AtPrepare_Notify().

Hmm, thinking about this a bit more, I don't think the messages should
be sent until commit (ie. 2nd phase). Although the information is safe
in the state file, if anyone starts to LISTEN between the PREPARE
TRANSACTION and COMMIT PREPARED calls, he would miss the notifications.
I'm not sure if it's well-defined what happens if someone starts to
LISTEN while another transaction has already sent a notification, but it
would be rather surprising if such a window existed where it doesn't
exist with non-prepared transactions.

A better approach is to do something similar to what we do now: at
prepare, just store the notifications in the state file like we do
already. In notify_twophase_postcommit(), copy the messages to the
shared queue. Although it's the same approach we have now, it becomes a
lot cleaner with the patch, because we're not piggybacking the messages
on the backend-private queue of the current transaction, but sending the
messages directly on behalf of the prepared transaction being committed.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com