On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Brendan Jurd wrote:
>> However, given the <tumbleweed/> response to my original email,
>> it's likely that effort would be a waste of time.
>
> I think tumbleweed responses are more in line with "hmm, this guy might
> well be right, but I don't know right now. <next email>". When people
> come up with really useless proposals, they tend to figure out pretty
> quickly.
+1
It took me a lot longer than it should have to figure this out, but
lack of comment does not in any way indicate a response is bad. Most
commonly it means, "interesting idea, why don't you code it up and see
what happens?". Suggestions, even very good ones (except when related
to bona fide bugs) are remarkably unlikely to elicit, "good idea,
let's do that!".
Álvaro, Merlin,
Thanks for your comments. I understand what you're saying, and I do agree for the most part. However I've also seen the downside of this, where nobody comments much on the original proposal, and only after sinking substantial effort into creating a patch do others appear to forcefully oppose the idea that led to the patch. I do understand why it happens this way, but that doesn't make it any less of a deterrent.
If you see a proposal on the list and you think "interesting idea, why don't you code it up and see what happens", I would humbly and respectfully encourage you to type exactly those words in to your email client and let the author of the proposal know. None of us are telepaths, silence is ambiguous, and sometimes even a very small encouragement is all that is needed to provoke action.
Back to the $subject at hand -- I have had a quick look into async.c and can see that the logic to test for queue size in asyncQueueFillWarning() could easily be factored out and exposed via an SQL function. My original idea was to have the function return the number of notifications in the queue, but in fact given the way notifications are stored, it would be much easier to return a float showing the fraction of the maximum queue size that is currently occupied. This would actually be more useful for the use-case I described, where I am wanting to monitor for rogue processes filling up the queue.
I will take Merlin's advice, code something up and see what happens.
Cheers,
BJ
