Hoi Tom,
On Sun, 24 Nov 2019 at 02:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> This seems both undesirable for our own testing, and rather bogus
> from users' standpoints as well. However, I think a simple fix is
> available: just make the SQL pg_notification_queue_usage() function
> advance the queue tail before measuring, as in 0002 below. This will
> restore the behavior of that function to what it was before 51004c717,
> and it doesn't seem like it'd cost any performance in any plausible
> use-cases.
This was one of those open points in the previous patches where it
wasn't quite clear what the correct behaviour should be. This fixes
the issue, but the question in my mind is: do we want to document this
fact and can users rely on this behaviour? If we go with the argument
that the delay in cleaning up should be entirely invisible, then I
guess this patch is the correct one that makes the made changes
invisible. Arguably not doing this means we'd have to document the
values are possibly out of date.
So I think this patch does the right thing.
Have a nice day,
--
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/