Em seg., 22 de jun. de 2020 às 23:29, David Rowley <dgrowle...@gmail.com> escreveu:
> On Tue, 23 Jun 2020 at 07:33, Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Jun 22, 2020 at 12:47 PM Ranier Vilela <ranier...@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. > Yes, I understand that focus here is I/O. Sorry, by the noise. regards, Ranier Vilela
