On Mon, Aug 17, 2020 at 11:38 AM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > > On Sat, 15 Aug 2020 at 12:19, Amit Kapila <amit.kapil...@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.
v6-0001-Add-additional-information-in-vacuum-errcontext.patch
Description: Binary data
v6-0002-additinal-error-context-information-in-heap_page_.patch
Description: Binary data
