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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers