Em seg., 22 de jun. de 2020 às 23:29, David Rowley <dgrowleyml@gmail.com> escreveu:
On Tue, 23 Jun 2020 at 07:33, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Jun 22, 2020 at 12:47 PM Ranier Vilela <ranier.vf@gmail.com> wrote: > > Questions: > > 1. Why acquire and release lock in retry: loop. > > This is a super-bad idea. Note the coding rule mentioned in spin.h. > There are many discussion on this mailing list about the importance of > keeping the critical section for a spinlock to a few instructions. > Calling another function that *itself acquires an LWLock* is > definitely not OK.
Just a short history lesson for Ranier to help clear up any confusion:
Back before 3cda10f41 there was some merit in improving the performance of these functions. Before that, we used to dish out pages under a lock. With that old method, if given enough workers and a simple enough query, we could start to see workers waiting on the lock just to obtain the next block number they're to work on. After the atomics were added in that commit, we didn't really see that again.
It is a good explanation. I already imagined it could be to help other processes, but I still wasn't sure. However, I did a test with this modification (lock before retry), and it worked.
What we're trying to fix here is the I/O pattern that these functions induce and that's all we should be doing here. Changing this is tricky to get right as we need to consider so many operating systems and how they deal with I/O readahead.