From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>,
        Melanie Plageman <melanieplageman@gmail.com>,
        Peter Geoghegan <pg@bowt.ie>, Heikki Linnakangas <hlinnaka@iki.fi>,
        Pg Hackers <pgsql-hackers@postgresql.org>,
        Noah Misch <noah@leadboat.com>
Subject: Re: Vacuum ERRORs out considering freezing dead tuples from before
 OldestXmin
In-reply-to: <Zp74YAbnyi_yARGT@paquier.xyz>
References: 
 <CAAKRu_bQFifK3U=VGKpR5MXLaCWHZ-jf0N6xJvMnf_XYB2OR9A@mail.gmail.com>
 <CAH2-WznnDZgZAOUins9ye8_=Y=892N2mvjs9bUB8s37gXnOKQQ@mail.gmail.com>
 <CAAKRu_b+9i71Kk4MB3SxFMzox84En=v+X31sFvRzJ-ZsXVi0qw@mail.gmail.com>
 <614152.1721580711@sss.pgh.pa.us>
 <CAH2-Wz=3TJ86JF_Puv7zThOxZKAVyiNZED_4bxGEdRyftGY5Vg@mail.gmail.com>
 <729493.1721595882@sss.pgh.pa.us>
 <CAAKRu_ZZrbQrYaGrMHG1YTUfP=p88sJ0YSXdFMzYX61MNQJ9gg@mail.gmail.com>
 <889997.1721663290@sss.pgh.pa.us>
 <CA+TgmobN+5uDPdwyPJqTWdvvJqXqztB26C=RxyTRVXmuxaKkcw@mail.gmail.com>
 <20240722173717.jq67ij75bleau6pb@awork3.anarazel.de>
 <Zp74YAbnyi_yARGT@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Tue, 23 Jul 2024 09:25:04 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <950880.1721695034.1@sss.pgh.pa.us>
Date: Mon, 22 Jul 2024 20:37:14 -0400
Message-ID: <950881.1721695034@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/950881.1721695034%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> Sawada-san and John are the two ones in the best position to answer
> that.  I'm not sure either how to force a second index pass, either.

Yeah, I think we've established that having some way to force that,
without using a huge test case, would be really desirable.  Maybe
just provide a way to put an artificial limit on how many tuples
processed per pass?

(And no, I wasn't trying to rag on Melanie.  My point here is that
we've failed to design-in easy testability of this code path, and
that's surely not her fault.)

			regards, tom lane