Re: collect_corrupt_items_vacuum.patch

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Daniel Shelepanov <deniel1495(at)mail(dot)ru>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: collect_corrupt_items_vacuum.patch
Date: 2023-11-06 09:30:15
Message-ID: CAPpHfdu6c=dQHq4r_xXbcAu0T4P28wv6x7QTwBZa7idv6nZsrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

On Tue, Jul 4, 2023 at 10:21 AM Daniel Gustafsson <daniel(at)yesql(dot)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

Attachment Content-Type Size
0001-Fix-false-reports-in-pg_visibility-v2.patch application/octet-stream 4.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-11-06 09:31:41 Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Previous Message Dilip Kumar 2023-11-06 09:21:04 Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock