Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
Date
Msg-id Yp6OJ37rmJfJbAUd@paquier.xyz
Whole thread Raw
In response to Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Mon, Jun 06, 2022 at 01:53:35PM -0500, Justin Pryzby wrote:
> It seems important to use a format in most-significant-parts-first which sorts
> nicely by filename, but otherwise anything could be okay.

Agreed.

> Apparently, that's ISO 8601, which can optionally use separators
> (YYYY-MM-DDTHH:MM:SS).

OK, let's use a T, with the basic format and a minimal number of
separators then, we get 20220603T082255.

> I was thinking this would not include fractional seconds.  Maybe that would
> mean that the TAP tests would need to sleep(1) at some points...

If we don't split by the millisecond, we would come back to the
problems of the original report.  On my laptop, the --check phase
that passes takes more than 1s, but the one that fails takes 0.1s, so
a follow-up run would complain with the path conflicts.  So at the end
I would reduce the format to be YYYYMMDDTHHMMSS_ms (we could also use
a logic that checks for conflicts and appends an extra number if
needed, though the addition of the extra ms is a bit shorter).
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: replacing role-level NOINHERIT with a grant-level option
Next
From: David Rowley
Date:
Subject: Re: Reducing Memory Consumption (aset and generation)