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.
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
On Fri, Dec 17, 2021 at 09:47:05AM -0500, Bruce Momjian wrote:
> On Fri, Dec 17, 2021 at 10:21:04AM +0100, Peter Eisentraut wrote:
>> I think that is reasonable.
Thanks. I have applied that, as that really helped here.
>> Maybe we could have some global option, like some environment variable, th
On Fri, Dec 17, 2021 at 10:21:04AM +0100, Peter Eisentraut wrote:
> On 16.12.21 07:50, Michael Paquier wrote:
> > As per $subject, avoiding the flush of the new cluster's data
> > directory shortens a bint the runtime of the test. In some of my slow
> > VMs, aka Windows, this shaves a couple of se
On 16.12.21 07:50, Michael Paquier wrote:
As per $subject, avoiding the flush of the new cluster's data
directory shortens a bint the runtime of the test. In some of my slow
VMs, aka Windows, this shaves a couple of seconds even if the bulk of
the time is still spent on the main regression test
