Hi! On Tue, Jul 4, 2023 at 10:21 AM Daniel Gustafsson <dan...@yesql.se> wrote: > This patch has been waiting on the author for about a year now, so I will > close > it as Returned with Feedback. Plesae feel free to resubmit to a future CF > when > there is renewed interest in working on this.
I'd like to revive this thread. While the patch proposed definitely makes things better. But as pointed out by Robert and Tom, it didn't allow to avoid all false reports. The reason is that the way we currently calculate the oldest xmin, it could move backwards (see comments to ComputeXidHorizons()). The attached patch implements own function to calculate strict oldest xmin, which should be always greater or equal to any xid horizon calculated before. I have to do the following changes in comparison to what ComputeXidHorizons() do. 1. Ignore processes xmin's, because they take into account connection to other databases which were ignored before. 2. Ignore KnownAssignedXids, because they are not database-aware. While primary could compute its horizons database-aware. 3. Ignore walsender xmin, because it could go backward if some replication connections don't use replication slots. Surely these would significantly sacrifice accuracy. But we have to do so in order to avoid reporting false errors. Any thoughts? ------ Regards, Alexander Korotkov
0001-Fix-false-reports-in-pg_visibility-v2.patch
Description: Binary data
