On Mon, Oct 10, 2016 at 5:55 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Sep 29, 2016 at 8:27 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > > On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas <robertmh...@gmail.com> > wrote: > > > >> Another thing I don't quite understand about this algorithm is that in > >> order to conditionally lock the target primary bucket page, we'd first > >> need to read and pin it. And that doesn't seem like a good thing to > >> do while we're holding a shared content lock on the metapage, because > >> of the principle that we don't want to hold content locks across I/O. > >> > > > > Aren't we already doing this during BufferAlloc() when the buffer > selected by StrategyGetBuffer() is dirty? > Right, you probably shouldn't allocate another buffer while holding a content lock on a different one, if you can help it. But, BufferAlloc doesn't do that internally, does it? It is only a problem if you make it be one by the way you use it. Am I missing something? > > > I think we can release metapage content lock before reading the buffer. > > > > On thinking about this again, if we release the metapage content lock > before reading and pinning the primary bucket page, then we need to > take it again to verify if the split has happened during the time we > don't have a lock on a metapage. Releasing and again taking content > lock on metapage is not > good from the performance aspect. Do you have some other idea for this? > Doesn't the relcache patch effectively deal wit hthis? If this is a sticking point, maybe the relcache patch could be incorporated into this one. Cheers, Jeff
