From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Understanding when VM record needs snapshot conflict horizon |
Date: | 2025-05-27 19:48:29 |
Message-ID: | CAAKRu_ZZ8jzUSs_Lvjr3N9XbYFFe99zczT3_uM5tZuCeT2CfXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, May 25, 2025 at 6:45 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> 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.
Yep, that's a good point. In my patch set to combine the prune/freeze
record and visible record, the only time we could omit the snapshot
conflict horizon after phase I of vacuum in this combined record is
when the heap page was unmodified by phase I and the heap page was
already marked all-visible in the VM and is only being set all-frozen.
I will make sure that the snapshot conflict horizon is omitted in that
case to ensure we don't spend more time on the standby to check for
conflicts.
- Melanie
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-05-27 19:51:40 | Re: Tightening DecodeNumberField's parsing rules |
Previous Message | Robert Haas | 2025-05-27 19:18:50 | Re: Non-reproducible AIO failure |