On Thu, May 2, 2019 at 4:57 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, May 2, 2019 at 12:39 PM John Naylor <john.nay...@2ndquadrant.com> > wrote: > > > Okay, I have updated the patch to incorporate your changes and call > relcache invalidation at required places. I have updated comments at a > few places as well. The summarization of this patch is that (a) it > moves the local map to relation cache (b) performs the cache > invalidation whenever we create fsm (either via backend or vacuum), > when some space in a page is freed by vacuum (provided fsm doesn't > exist) or whenever the local map is cleared (c) additionally, we clear > the local map when we found a block from FSM, when we have already > tried all the blocks present in cache or when we are allowed to create > FSM. > > If we agree on this, then we can update the README accordingly. > > Can you please test/review?
There isn't enough time. But since I already wrote some debugging calls earlier (attached), I gave it a brief spin, I found this patch isn't as careful as HEAD making sure we don't try the same block twice in a row. If you insert enough tuples into an empty table such that we need to extend, you get something like this: DEBUG: Not enough space on block 0 DEBUG: Now trying block 0 DEBUG: Not enough space on block 0 DEBUG: Updating local map for block 0 At this point, I'm sorry to say, but I'm in favor of reverting. There just wasn't enough time to redesign and debug a feature like this during feature freeze. -- John Naylor https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
debug-free-space.patch
Description: Binary data