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

On Mon, Nov 16, 2009 at 9:05 AM, Greg Sabino Mullane >> We still need
to decide what to do with queue full situations in
>> the proposed listen/notify implementation. I have a new version
>> of the patch to allow for a variable payload size. However, the
>> whole notification must fit into one page so the payload needs
>> to be less than 8K.
>
> That sounds fine to me, FWIW.

+1! I think this should satisfy everyone.

>> I have also added the XID, so that we can write to the queue before
>> committing to clog which allows for rollback if we encounter write
>> errors (disk full for example). Especially the implications of this
>> change make the patch a lot more complicated.
>
> Can you elaborate on the use case for this?

Tom specifically asked for it: "The old implementation was acid so the
new one should be to"

>> so it won't update its pointer for some time. With the current space we can
>> acommodate at least 2147483647 notifications or more, depending on the
>> payload length.
>
> That's a whole lot of notifications. I doubt any program out there is using
> anywhere near that number at the moment. In my applications, having a
> few hundred notifications active at one time is "a lot" in my book. :)
>
>> These are the solutions that I currently see:
>>
>> 1) drop new notifications if the queue is full (silently or with rollback)
>
> I like this one best, but not with silence of course. While it's not the most
> polite thing to do, this is for a super extreme edge case. I'd rather just
> throw an exception if the queue is full rather than start messing with the
> readers. It's a possible denial of service attack too, but so is the current
> implementation in a way - at least I don't think apps would perform very
> optimally with 2147483647 entries in the pg_listener table :)
>
> If you need some real-world use cases involving payloads, let me know, I've
> been waiting for this feature for some time and have it all mapped out.

me too. Joachim: when I benchmarked the original patch, I was seeing
a few log messages that suggested there might be something going
inside. In any event, the performance was fantastic.

merlin