Re: Intermittent buildfarm failures on wrasse
От | Tom Lane |
---|---|
Тема | Re: Intermittent buildfarm failures on wrasse |
Дата | |
Msg-id | 1374062.1649896550@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Intermittent buildfarm failures on wrasse (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Intermittent buildfarm failures on wrasse
Re: Intermittent buildfarm failures on wrasse |
Список | pgsql-hackers |
Peter Geoghegan <pg@bowt.ie> writes: > On Wed, Apr 13, 2022 at 4:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Yeah, we have band-aided around this type of problem repeatedly. >> Making a fix that's readily accessible from any test script >> seems like a good idea. > We might even be able to consistently rely on this new option, given > *any* problem involving test stability and VACUUM. Having a > one-size-fits-all solution to these kinds of stability problems would > be nice -- no more DISABLE_PAGE_SKIPPING bandaids. 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. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: