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

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
Date: 2022-06-06 18:53:35
Message-ID: 20220606185335.GY29853@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)paquier(dot)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(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2022-06-06 18:59:17 Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list
Previous Message Stephen Frost 2022-06-06 18:52:03 Re: pgsql: Use pre-fetching for ANALYZE