Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
Дата
Msg-id Yp6OJ37rmJfJbAUd@paquier.xyz
обсуждение исходный текст
Ответ на Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch  (Michael Paquier <michael@paquier.xyz>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: replacing role-level NOINHERIT with a grant-level option
Следующее
От: David Rowley
Дата:
Сообщение: Re: Reducing Memory Consumption (aset and generation)