On Tue, Jun 3, 2025 at 2:00 PM Peter Geoghegan wrote:
>
> On Mon, Jun 2, 2025 at 4:00 PM Melanie Plageman
> wrote:
> > Perhaps I could keep track of the newest modified xid or some such
> > thing that is the newer of the newest removed xmax and newest frozen
> > xmin.
>
> BTW, I don't think that
On Tue, Jun 3, 2025 at 1:59 PM Peter Geoghegan wrote:
> We do currently end up using OldestXmin-1 as our
> snapshotConflictHorizon when this happens, but as I said in the other
> email, I don't think that that's really required.
Actually, that's not really true, either. That is, it is possible
(t
On Mon, Jun 2, 2025 at 4:00 PM Melanie Plageman
wrote:
> Perhaps I could keep track of the newest modified xid or some such
> thing that is the newer of the newest removed xmax and newest frozen
> xmin.
BTW, I don't think that you have to worry about removing/freezing xmax
when it comes to genera
On Mon, Jun 2, 2025 at 4:00 PM Melanie Plageman
wrote:
> I think, however, that I can't avoid keeping a separate counter for
> the horizon for the VM record. Pruning and freezing horizon is the
> newest "modified" (pruned or frozen) tuple xid, whereas the VM record
> needs the newest live committe
On Mon, Jun 2, 2025 at 3:40 PM Peter Geoghegan wrote:
>
> On Mon, Jun 2, 2025 at 3:30 PM Melanie Plageman
> wrote:
>
> > But, for cases when a few tuples are frozen on the page, it seems like it
> > could
> > be worth it?
>
> In general, I don't expect that we're all that likely to freeze some
>
On Mon, Jun 2, 2025 at 3:40 PM Melanie Plageman
wrote:
> Oh, and, more specifically, in my previous email, I was wondering if,
> and why, in 16 this diff wouldn't be correct
I *think* that it would be correct.
Again, it is certainly possible to make the conflict horizon precisely
the oldest safe
On Mon, Jun 2, 2025 at 3:05 PM Peter Geoghegan wrote:
>
> On Mon, Jun 2, 2025 at 2:50 PM Melanie Plageman
> wrote:
> > As you've explained, it will always be <= OldestXmin. And, if the
> > record only freezes tuples (meaning it makes no other changes to the
> > page) and all of those tuples' xmin
On Mon, Jun 2, 2025 at 3:30 PM Melanie Plageman
wrote:
> I understand that if I wanted to actually use the newest frozen xmin
> as the conflict horizon when the page is not all-frozen, I'd need a
> new counter since visibility_cutoff_xid is calculated across all live
> tuples older than OldestXmin
On Mon, Jun 2, 2025 at 3:05 PM Peter Geoghegan wrote:
>
> On Mon, Jun 2, 2025 at 2:50 PM Melanie Plageman
> wrote:
> > As you've explained, it will always be <= OldestXmin. And, if the
> > record only freezes tuples (meaning it makes no other changes to the
> > page) and all of those tuples' xmin
On Mon, Jun 2, 2025 at 2:50 PM Melanie Plageman
wrote:
> As you've explained, it will always be <= OldestXmin. And, if the
> record only freezes tuples (meaning it makes no other changes to the
> page) and all of those tuples' xmins were considered when calculating
> prunestate->visibility_cutoff_
On Thu, May 29, 2025 at 11:37 AM Peter Geoghegan wrote:
>
> Your concern is that the horizon might be overly aggressive/too
> conservative. But your patch (for 16) makes us take the
> don't-use-snapshotConflictHorizon-twice block *less* frequently (and
> the "use OldestXmin conservatively" block *
On Fri, May 30, 2025 at 6:10 PM Peter Geoghegan wrote:
>
> On Fri, May 30, 2025 at 5:57 PM Melanie Plageman
> wrote:
> > I don't see how OldestXmin comes into play with the visibility_cutoff_xid.
>
> Code in heap_page_is_all_visible() (and other place, I guess the other
> one is in pruneheap.c no
On Fri, May 30, 2025 at 5:57 PM Melanie Plageman
wrote:
> I don't see how OldestXmin comes into play with the visibility_cutoff_xid.
Code in heap_page_is_all_visible() (and other place, I guess the other
one is in pruneheap.c now) have a separate OldestXmin test:
/*
* The inserter definitely co
On Fri, May 30, 2025 at 5:34 PM Peter Geoghegan wrote:
>
> On Fri, May 30, 2025 at 5:16 PM Melanie Plageman
> wrote:
>
> > You're right. I forgot that the visibility_cutoff_xid will be older
> > than OldestXmin when all the tuples are going to be frozen.
>
> I added an assertion in a number of pl
On Fri, May 30, 2025 at 5:16 PM Melanie Plageman
wrote:
> On Thu, May 29, 2025 at 11:37 AM Peter Geoghegan wrote:
> > How can taking the "Avoids false conflicts when hot_standby_feedback
> > in use" path more often result in fewer unnecessary conflicts on
> > standbys? Isn't it the other way arou
On Thu, May 29, 2025 at 11:37 AM Peter Geoghegan wrote:
>
> Your concern is that the horizon might be overly aggressive/too
> conservative. But your patch (for 16) makes us take the
> don't-use-snapshotConflictHorizon-twice block *less* frequently (and
> the "use OldestXmin conservatively" block *
On Thu, May 29, 2025 at 10:57 AM Melanie Plageman
wrote:
> However, we calculate the snapshot conflict horizon for the
> prune/freeze record in master/17 and the freeze record in 16 before
> updating all-frozen and all-visible. That means the horizon may be too
> aggressive if the page cannot actu
Hi,
I noticed while writing another patch that I think there might be an
issue/oversight with how the snapshot conflict horizon is calculated
for the prune/freeze WAL record in master/17 and the freeze WAL record
in 16.
In code to determine whether or not to freeze tuples on the page in
phase I o
18 matches
Mail list logo
