On Tuesday, November 17, 2020 9:40 AM, Tsunkawa-san wrote:
> From: Thomas Munro <thomas.munro@gmail.com>
> > On Mon, Nov 16, 2020 at 11:01 PM Konstantin Knizhnik
> > <k.knizhnik@postgrespro.ru> wrote:
> > > I will look at your implementation more precisely latter.
> >
> > Thanks! Warning: I thought about making a thing like this for a
> > while, but the patch itself is only a one-day prototype, so I am sure
> > you can find many bugs... Hmm, I guess the smgrnblocks_fast() code
> > really needs a nice big comment to explain the theory about why this
> > value is fresh enough, based on earlier ideas about implicit memory
> > barriers. (Something like: if you're extending, you must have
> > acquired the extension lock; if you're scanning you must have acquired
> > a snapshot that only needs to see blocks that existed at that time and
> > concurrent truncations are impossible; I'm wondering about special
> > snapshots like VACUUM, and whether this is too relaxed for that, or if
> > it's covered by existing horizon-based interlocking...).
>
> We'd like to join the discussion and review, too, so that Kirk's optimization for
> VACUUM truncation and TRUNCATRE can extend beyond recovery to
> operations during normal operation. In that regard, would you mind
> becoming a committer for his patch? We think it's committable now. I'm
> fine with using the unmodified smgrnblocks() as your devil's suggestion.
Just saw this thread has been bumped. And yes, regarding the vacuum and truncate
optimization during recovery, it would still work even without the unmodified smgrnblocks.
We'd just need to remove the conditions that checks the flag parameter. And if we explore
your latest prototype patch, it can possibly use the new smgrnblocks_xxxx APIs introduced here.
That said, we'd like to explore the next step of extending the feature to normal operations.
Regards,
Kirk Jamison