On Mon, Aug 17, 2020 at 11:38 AM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Sat, 15 Aug 2020 at 12:19, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > The reason why I have not included heap_page_prune related change in
> > the patch is that I don't want to sprinkle this in every possible
> > function (code path) called via vacuum especially if the probability
> > of an error in that code path is low. But, I am fine if you and or
> > others think that it is a good idea to update offset in
> > heap_page_prune as well.
>
> I agree to not try sprinkling it many places than necessity.
>
> Regarding heap_page_prune(), I'm concerned a bit that
> heap_page_prune() is typically the first function to check the tuple
> visibility within the vacuum code. I've sometimes observed an error
> with the message like "DETAIL: could not open file “pg_xact/00AB”: No
> such file or directory" due to a tuple header corruption. I suspect
> this message was emitted while checking tuple visibility in
> heap_page_prune(). So I guess the likelihood of an error in that code
> is not so low.
>
Fair point.
> On the other hand, if we want to update the offset number in
> heap_page_prune() we will need to expose some vacuum structs defined
> as a static including LVRelStats.
>
I don't think we need to expose LVRelStats. We can just pass the
address of vacrelstats->offset_num to achieve what we want. I have
tried that and it works, see the
v6-0002-additinal-error-context-information-in-heap_page_ patch
attached. Do you see any problem with it?
--
With Regards,
Amit Kapila.
