Re: collect_corrupt_items_vacuum.patch - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: collect_corrupt_items_vacuum.patch
Date
Msg-id CAN-LCVMWxCvraFrGWxMtvkqrkSYZhCoOixR8a2sOjSCgG_pgrw@mail.gmail.com
Whole thread Raw
In response to Re: collect_corrupt_items_vacuum.patch  (Nikita Malakhov <hukutoc@gmail.com>)
Responses Re: collect_corrupt_items_vacuum.patch  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Hi hackers!

Just to bump this thread, because the problem seems to be still actual:

Please correct me if I am wrong. I've checked another discussion related to pg_visibility [1]. 
According to discussion: if using latest completed xid is not right for checking visibility, than
it should be the least running transaction xid? So it must be another function to be used for
these calculations, not the GetOldestNonRemovableTransactionId that uses
the ComputeXidHorizons.


On Wed, Oct 12, 2022 at 8:15 AM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Jul 27, 2022 at 09:47:19PM -0400, Robert Haas wrote:
> On Wed, Jul 27, 2022 at 5:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Maybe we need a different function for pg_visibility to call?
> > If we want ComputeXidHorizons to serve both these purposes, then it
> > has to always deliver exactly the right answer, which seems like
> > a definition that will be hard and expensive to achieve.
>
> Yeah, I was thinking along similar lines.
>
> I'm also kind of wondering why these calculations use
> latestCompletedXid. Is that something we do solely to reduce locking?
> The XIDs of running transactions matter, and their snapshots matter,
> and the XIDs that could start running in the future matter, but I
> don't know why it matters what the latest completed XID is.

Daniel, it seems to me that this thread is waiting for some input from
you, based on the remarks of Tom and Robert.  Are you planning to do
so?  This is marked as a bug fix, so I have moved this item to the
next CF for now.
--
Michael

--
Regards,
Nikita Malakhov
Postgres Professional 

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: wake up logical workers after ALTER SUBSCRIPTION
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: Raising the SCRAM iteration count