On 2021-Aug-20, Bossart, Nathan wrote:
> > On Fri, Aug 20, 2021 at 1:29 PM Bossart, Nathan <bossartn@amazon.com> wrote:
> >> This led me to revisit the two-element
> >> approach that was discussed upthread. What if we only stored the
> >> earliest and latest segment boundaries at any given time? Once the
> >> earliest boundary is added, it never changes until the segment is
> >> flushed and it is removed. The latest boundary, however, will be
> >> updated any time we register another segment. Once the earliest
> >> boundary is removed, we replace it with the latest boundary. This
> >> strategy could cause us to miss intermediate boundaries, but AFAICT
> >> the worst case scenario is that we hold off creating .ready files a
> >> bit longer than necessary.
> I've attached a patch to demonstrate what I'm thinking.
There is only one thing I didn't like in this new version, which is that
we're holding info_lck too much. I've seen info_lck contention be a
problem in some workloads and I'd rather not add more stuff to it. I'd
rather we stick with using a new lock object to protect all the data we
need for this job.
Should this new lock object be a spinlock or an lwlock? I think a
spinlock would generally be better because it's lower overhead and we
can't use it in shared mode anywhere, which would be the greatest
argument for an lwlock. However, I think we avoid letting code run with
spinlocks held that's not straight-line code, and we have some function
calls there.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
