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

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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.

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

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.

On the whole I'd be just as happy to disallow NOTIFY in a 2PC
transaction. We have no evidence that anyone out there is using the
combination, and if they are, they can do the work to make it safe.

regards, tom lane