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

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

>> As a user I would expect the logs from this current invocation to be removed
>> without --retain, and any other older log entries be kept. I think we should
>> remove log_opts.logdir and only remove log_opts.rootdir if it is left empty
>> after .logdir is removed.
>
> Okay, however I think you mean log_opts.basedir rather than logdir?
> That's simple enough to switch around as pg_check_dir() does this
> job.

Correct, I mistyped. The cleanup in this version of the patch looks sane to
me.

--
Daniel Gustafsson https://vmware.com/