Re: pg_upgrade should truncate/remove its logs before running

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_upgrade should truncate/remove its logs before running
Date: 2022-01-25 16:45:29
Message-ID: 20220125164529.GG23027@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 24, 2022 at 10:59:40AM +0900, Michael Paquier wrote:
> On Thu, Jan 20, 2022 at 07:51:37PM +0900, Michael Paquier wrote:
> > Neat idea. That would work fine for my case. So I am fine to stick
> > with this suggestion.
>
> I have been looking at this idea, and the result is quite nice, being
> simpler than anything that has been proposed on this thread yet. We
> get a simpler removal logic, and there is no need to perform any kind
> of sanity checks with the output path provided as long as we generate
> the paths and the dirs after adjust_data_dir().
>
> Thoughts?

Andrew: you wanted to accommodate any change on the build client, right ?

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh Thalor 2022-01-25 16:56:01 Re: Collecting statistics about contents of JSONB columns
Previous Message Mark Dilger 2022-01-25 16:42:14 Re: CREATEROLE and role ownership hierarchies