Re: pg_stat_statements locking

> On 12 Sep 2022, at 23:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andrey Borodin <x4mmm@yandex-team.ru> writes:
>>> On 12 Sep 2022, at 18:18, Julien Rouhaud <rjuju123@gmail.com> wrote:
>>> That being
>>> said I don't know if adding a timeout would be too expensive for the lwlock
>>> infrastructure.
>
> I want to object fiercely to loading down LWLock with anything like
> timeouts.  It's supposed to be "lightweight".  If we get away from
> that we're just going to find ourselves needing another lighter-weight
> lock mechanism.

Thanks for clarifying this out, Tom. I agree that spreading timeout-based algorithms is not a good thing. And when you
havea hammer - everything seems like a nail, so it would be temping to use timeout here and there. 


> On 12 Sep 2022, at 23:08, Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> That's what I was thinking, so it looks like a show-stopper for the proposed
> patch.

So, the only option to make things configurable is a switch for waiting\waitless locks.

And the other way is refactoring towards partitioned hashtable, namely dshash. But I don't see how partitioned locking
cansave us from a locking disaster. Problem is caused by reading all the pgss view colliding with reset() or GC. Both
thisoperations deal with each partition - they will conflict anyway, with the same result. Time-consuming read of each
partitionwill prevent exclusive lock by reset(), and queued exclusive lock will prevent any reads from hashtable. 


Best regards, Andrey Borodin.