On Sat, May 24, 2025 at 2:21 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> On Fri, May 23, 2025 at 12:04 PM Andres Freund <andres@anarazel.de> wrote:
> 3) if you are updating the VM and you are not modifying the heap page
> at all, then you don't need to include a snapshot conflict horizon in
> the record because you can safely assume that a record with the
> visibility cutoff xid for that heap page as the snapshot conflict
> horizon has already been emitted. And any existing snapshots that
> would conflict with it would have conflicted with the previous record.
>
> I think 3 can only happen if something goes wrong with the VM -- like
> it is lost somehow.
>
> What I am wondering is if it is worth omitting the snapshot conflict
> horizon in the third case.
> Currently, you would emit an xl_heap_visible record with
> InvalidTransactionId as the conflict horizon in this case. But you
> aren't saving any space and it doesn't seem like you are saving any
> queries from being canceled by not doing this. It simply makes the
> logic for what to put in the WAL record more complicated.
>
IMHO, if we include snapshot conflict horizon in cases where it is not
necessary, don't you think it will impact performance on standby?
because now it has to loop through the procarray on standby to check
whether there is any conflict before applying this WAL.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
