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