On Wed, Jul 17, 2024 at 11:07 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> On Mon, Jul 15, 2024 at 6:02 PM Peter Geoghegan <pg@bowt.ie> wrote:
> >
> > I think that there is some chance that this test will break the build
> > farm in whatever way, since there is a long history of VACUUM not
> > quite behaving as expected with these sorts of tests. I think that you
> > should commit the test case separately, first thing in the morning,
> > and then keep an eye on the build farm for the rest of the day. I
> > don't think that it's sensible to bend over backwards, just to avoid
> > breaking the build farm in this way.
>
> Sounds good.
Hmm. So, I was just running all the versions through CI again, and I
noticed that the test failed on master on CI on Linux - Debian
Bookworm with Meson. (This passes locally for me and has passed on
previous CI runs).
[15:43:41.547] stderr:
[15:43:41.547] # poll_query_until timed out executing this query:
[15:43:41.547] #
[15:43:41.547] # SELECT index_vacuum_count > 0
[15:43:41.547] # FROM pg_stat_progress_vacuum
[15:43:41.547] # WHERE datname='test_db' AND relid::regclass =
'vac_horizon_floor_table'::regclass;
[15:43:41.547] #
[15:43:41.547] # expecting this output:
[15:43:41.547] # t
[15:43:41.547] # last actual query output:
[15:43:41.547] # f
We didn't end up doing two index vacuum passes. Because it doesn't
repro locally for me, I can only assume that the conditions for
forcing two index vacuuming passes in master just weren't met in this
case. I'm unsurprised, as it is much harder since 17 to force two
passes of index vacuuming. It seems like this might be as unstable as
I feared. I could add more dead data. Or, I could just commit the test
to the back branches before 17. What do you think?
- Melanie