From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Intermittent buildfarm failures on wrasse |
Date: | 2022-04-14 01:03:54 |
Message-ID: | CAH2-Wz=kB2KMGFivRVOHA6HwVkWMHwj_JRYQie4rA3Z4xWv5tw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 13, 2022 at 5:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> My guess is that you'd need both this new wait-for-horizon behavior
> *and* DISABLE_PAGE_SKIPPING. But the two together ought to make
> for pretty reproducible behavior. I noticed while scanning the
> commit log that some patches have tried adding a FREEZE option,
> which seems more like waving a dead chicken than anything that'd
> improve stability.
I think that it's more likely that FREEZE will correct problems, out of the two:
* FREEZE forces an aggressive VACUUM whose FreezeLimit is as recent a
cutoff value as possible (FreezeLimit will be equal to OldestXmin).
* DISABLE_PAGE_SKIPPING also forces an aggressive VACUUM. But unlike
FREEZE it makes VACUUM not use the visibility map, even in the case of
all-frozen pages. And it changes nothing about FreezeLimit.
It's also a certainty that VACUUM(FREEZE, DISABLE_PAGE_SKIPPING) is
not a sensible remedy for any problem with test stability, but there
are still some examples of that combination in the regression tests.
The only way it could make sense is if the visibility map might be
corrupt, but surely we're not expecting that anyway (and if we were
we'd be testing it more directly).
I recently argued that DISABLE_PAGE_SKIPPING should have nothing to do
with aggressive vacuuming -- that should all be left up to VACUUM
FREEZE. It seems more logical to make DISABLE_PAGE_SKIPPING mean
"don't use the visibility map to skip anything", without bringing
aggressiveness into it at all. That would be less confusing.
> We'd not necessarily have to embed wait-for-horizon into VACUUM
> itself. It seems like a SQL-accessible function could be written
> and then called before any problematic VACUUM. I like this better
> for something we're thinking of jamming in post-feature-freeze;
> we'd not be committing to the feature quite as much as if we
> added a VACUUM option.
Hmm. I would say that the feature has zero appeal to users anyway.
Maybe it can and should be done through an SQL function for other
reasons, though. Users already think that there are several different
flavors of VACUUM, which isn't really true.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-04-14 01:05:05 | Re: Intermittent buildfarm failures on wrasse |
Previous Message | Andres Freund | 2022-04-14 00:59:00 | Re: Intermittent buildfarm failures on wrasse |