From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Addition of --no-sync to pg_upgrade for test speedup |
Date: | 2021-12-22 07:57:54 |
Message-ID: | YcLagpbD1cU6eABY@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 20, 2021 at 10:46:13AM -0300, Alvaro Herrera wrote:
> On 2021-Dec-16, Michael Paquier wrote:
>> In pg_upgrade, we let the flush happen with initdb --sync-only, based
>> on the binary path of the new cluster, so I think that we are not
>> going to miss any test coverage by skipping that.
>
> There was one patch of mine with breakage that only manifested in the
> pg_upgrade test *because* of its lack of no-sync. I'm afraid that this
> change would hide certain problems.
> https://postgr.es/m/20210130023011.n545o54j65t4kgxn@alap3.anarazel.de
Hmm. This talks about fsync=on being a factor counting in detecting a
failure with the backend. Why would the fsync done with initdb
--sync-only on the target cluster once pg_upgrade is done change
something here?
> I'm not 100% comfortable with this. What can we do to preserve *some*
> testing that include syncing? Maybe some option that a few buildfarm
> animals use?
If you object about this part, I am fine to revert the change in
test.sh until there is a better facility to enforce syncs across tests
in the buildfarm, though. I can hack something to centralize all
that, of course, but I am not sure when I'll be able to do so in the
short term. Could I keep that in MSVC's vcregress.pl at least for the
time being?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2021-12-22 08:01:24 | Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. |
Previous Message | Masahiko Sawada | 2021-12-22 07:57:11 | Re: Unifying VACUUM VERBOSE and log_autovacuum_min_duration output |