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

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
Дата
Msg-id 20220606185335.GY29853@telsasoft.com
обсуждение исходный текст
Ответ на Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch  (Daniel Gustafsson <daniel@yesql.se>)
Ответы 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 07:43:53PM +0200, Daniel Gustafsson wrote:
> > On 6 Jun 2022, at 06:17, Michael Paquier <michael@paquier.xyz> wrote:
> > On Mon, Jun 06, 2022 at 02:38:03AM +0200, Daniel Gustafsson wrote:
> >> On 5 Jun 2022, at 11:19, Michael Paquier <michael@paquier.xyz> wrote:
> 
> >>> I have been toying with the idea of a sub-directory named with a
> >>> timestamp (Unix time, like log_line_prefix's %n but this could be
> >>> any format) under pg_upgrade_output.d/ and finished with the
> >>> attached. 
> >> 
> >> I was thinking more along the lines of %m to make it (more) human readable, but
> >> I'm certainly not wedded to any format.

It seems important to use a format in most-significant-parts-first which sorts
nicely by filename, but otherwise anything could be okay.

> > Neither am I. I would not map exactly to %m as it uses whitespaces,
> > but something like %Y%m%d_%H%M%S.%03d (3-digit ms for last part) would
> > be fine? If there are other ideas for the format, just let me know.
> 
> I think this makes more sense from an end-user perspective.

Is it better to use "T" instead of "_" ?

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

https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations

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...

-- 
Justin



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: pgsql: Use pre-fetching for ANALYZE
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list