> On 1 Nov 2024, at 01:36, Bruce Momjian wrote:
> On Fri, Oct 25, 2024 at 01:55:57PM +0200, Daniel Gustafsson wrote:
>> In the meantime, the OP has a good point that it's a tad silly that
>> pg_upgrade
>> fails hard on invalid databases instead of detecting and reporting like how
>> other errors
On Fri, Oct 25, 2024 at 01:55:57PM +0200, Daniel Gustafsson wrote:
> > On 14 Oct 2024, at 18:57, Bruce Momjian wrote:
>
> > What might be acceptable would be to add an option that would make
> > pg_upgrade more tolerant of problems in many areas, that is a lot more
> > research and discussion.
>
> On 14 Oct 2024, at 18:57, Bruce Momjian wrote:
> What might be acceptable would be to add an option that would make
> pg_upgrade more tolerant of problems in many areas, that is a lot more
> research and discussion.
I agree that the concept of having pg_upgrade perform (opt-in) skipping and/or
On Sun, Oct 13, 2024 at 08:28:57AM -0400, Thomas Krennwallner wrote:
> In v2 I've made changes to the patch incorporating the suggestions here:
>
> * Default behaviour is to just fail with a report of all invalid databases
>
> * A new option --skip-invalid-databases will then skip the checks, and
On Fri, 11 Oct 2024 at 04:01, Daniel Gustafsson wrote:
>
> > On 7 Oct 2024, at 22:04, Nathan Bossart wrote:
> >
> > On Mon, Oct 07, 2024 at 03:37:35PM -0400, Bruce Momjian wrote:
> >> On Tue, Oct 1, 2024 at 09:28:54AM +0200, Daniel Gustafsson wrote:
> >>> Correct, sorry for being unclear. The c
> On 7 Oct 2024, at 22:04, Nathan Bossart wrote:
>
> On Mon, Oct 07, 2024 at 03:37:35PM -0400, Bruce Momjian wrote:
>> On Tue, Oct 1, 2024 at 09:28:54AM +0200, Daniel Gustafsson wrote:
>>> Correct, sorry for being unclear. The consistency argument would be to
>>> expand
>>> pg_upgrade to repor
On Mon, Oct 07, 2024 at 03:37:35PM -0400, Bruce Momjian wrote:
> On Tue, Oct 1, 2024 at 09:28:54AM +0200, Daniel Gustafsson wrote:
>> Correct, sorry for being unclear. The consistency argument would be to
>> expand
>> pg_upgrade to report all invalid databases rather than just the first found;
>
On Tue, Oct 1, 2024 at 09:28:54AM +0200, Daniel Gustafsson wrote:
> > On 1 Oct 2024, at 00:20, Tom Lane wrote:
> >
> > Daniel Gustafsson writes:
> >>> On 30 Sep 2024, at 16:55, Tom Lane wrote:
> >>> TBH I'm not finding anything very much wrong with the current
> >>> behavior... this has to be
> On 1 Oct 2024, at 00:20, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 30 Sep 2024, at 16:55, Tom Lane wrote:
>>> TBH I'm not finding anything very much wrong with the current
>>> behavior... this has to be a rare situation, do we need to add
>>> debatable behavior to make it easier?
>
> On 1 Oct 2024, at 02:35, Thomas Krennwallner wrote:
>
> On 30/09/2024 17.29, Daniel Gustafsson wrote:
>>> On 30 Sep 2024, at 16:55, Tom Lane wrote:
>>> TBH I'm not finding anything very much wrong with the current
>>> behavior... this has to be a rare situation, do we need to add
>>> debatable
On 30/09/2024 17.29, Daniel Gustafsson wrote:
On 30 Sep 2024, at 16:55, Tom Lane wrote:
TBH I'm not finding anything very much wrong with the current
behavior... this has to be a rare situation, do we need to add
debatable behavior to make it easier?
One argument would be to make the checks
Daniel Gustafsson writes:
>> On 30 Sep 2024, at 16:55, Tom Lane wrote:
>> TBH I'm not finding anything very much wrong with the current
>> behavior... this has to be a rare situation, do we need to add
>> debatable behavior to make it easier?
> One argument would be to make the checks consistent
> On 30 Sep 2024, at 16:55, Tom Lane wrote:
> TBH I'm not finding anything very much wrong with the current
> behavior... this has to be a rare situation, do we need to add
> debatable behavior to make it easier?
One argument would be to make the checks consistent, pg_upgrade generally tries
to
Nathan Bossart writes:
> Should we have pg_upgrade skip invalid databases? If the only valid action
> is to drop them, IMHO it seems unnecessary to require users to manually
> drop them before retrying pg_upgrade.
I was thinking the same. But I wonder if there is any chance of
losing data that
On Sun, Sep 29, 2024 at 08:45:50PM -0400, Thomas Krennwallner wrote:
> if a cluster contains invalid databases that we cannot connect to anymore,
> pg_upgrade would currently fail when trying to connect to the first
> encountered invalid database with
>
> [...]
>
> If there is more than one inval
15 matches
Mail list logo
