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

[Florian G. Pflug]

Tom Lane wrote:

Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:

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.

I'm not sure that it's really worth it, but one way this could be
made safe would be for PREPARE to "reserve" the required amount of
queue space, such that nobody else could use it during the window
from PREPARE to COMMIT PREPARED.

This is still ignoring the complaint: you are creating a clear risk that COMMIT PREPARED will fail.

I'd see no problem with "COMMIT PREPARED" failing, as long as it was
possible to retry the COMMIT PREPARED at a later time. There surely are
other failure cases for COMMIT PREPARED too, like an IO error that
prevents the clog bit from being set, or a server crash half-way through
COMMIT PREPARED.

best regards,
Florian Pflug

smime.p7s
Description: S/MIME Cryptographic Signature