Rishu Bagga <rishu.postgres@gmail.com> writes:
> To explore this further, I’ve drafted a patch that introduces a new GUC:
> `publish_out_of_order_notifications`.
We have generally found that GUCs that change query semantics turn
out to be very regrettable choices. They break applications that
aren't expecting it, and the granularity of the effect is frequently
not what you want either.
In the case at hand, I fear that a USERSET GUC is particularly
inappropriate, because what this proposal does is to break the
notification order guarantees system-wide, even if only one
issuer of notifications has it set.
> When enabled, this skips the global
> lock in `PreCommit_Notify`, allowing notifications to be queued in parallel.
How much does that really help, considering that we'll still serialize
on the NotifyQueueLock? I think that you'd need some rather
fundamental redesign to allow truly parallel queueing.
Stepping back a bit, my recollection is that "queue entries appear in
commit order" is a rather fundamental assumption in async.c, which we
rely on while dequeuing notifications. If that stops being true,
I think you'd have cases where listening backends fail to collect
available (committed) notifications because they appear in the queue
beyond not-yet-committed notifications. Maybe the window in which a
notification would remain uncommitted is short enough that we could
avert our eyes from that problem, but I'm not convinced.
So I sympathize with concerns about how well the notification code
scales, but I think you're going to have to do a ton more work than
this to get to anything that would pass muster to get committed.
In particular, I'd really want to see something that involves
explicitly opting-into out-of-order delivery on a per-NOTIFY basis,
because anything else will break too many applications. The
underlying queue mechanism is going to need a serious rethink, too.
My guess is that we'd need to move to something involving multiple
queues rather than just one, and I'm not very sure how that ought
to work. (But perhaps queuing in-order notifications separately
from not-guaranteed-in-order notifications would help? Or maybe
the latter should be transmitted in some other way entirely.)
regards, tom lane
