RE: [PoC] pg_upgrade: allow to upgrade publisher node

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: RE: [PoC] pg_upgrade: allow to upgrade publisher node
Date: 2023-09-19 06:17:45
Message-ID: TYAPR01MB586654CC748B51EB32A61EC0F5FAA@TYAPR01MB5866.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Amit,

Thank you for reviewing! PSA new version!

> > Sorry, wrong patch attached. PSA the correct ones.
> > There is a possibility that XLOG_PARAMETER_CHANGE may be generated,
> when GUC
> > parameters are changed just before doing the upgrade. Added to list.
> >
>
> You forgot to update 0002 patch for XLOG_PARAMETER_CHANGE.

Oh, I did wrong git operations locally. Sorry for inconvenience.

> I think it
> is okay to move walinspect's functionality into common place so that
> it can be used by this patch as suggested by Hou-San. The only reason
> it is okay to keep it specific to walinspect is if we want to enhance
> that functions for walinspect but I think if that happens then we can
> evaluate whether to enhance it by having additional parameters or
> creating something specific for walinspect.

OK, merged 0001 + 0002 into one.

> * +Datum
> +binary_upgrade_validate_wal_record_types_after_lsn(PG_FUNCTION_ARGS)
>
> How about naming it as binary_upgrade_validate_wal_records()? I don't
> see it is helpful to make it too long.

Agreed, fixed.

> Apart from this, I have made minor cosmetic changes in the attached.
> If these looks okay to you then you can include them in next version.

Seems better, included.

Apart from above, I fixed not to call binary_upgrade_validate_wal_records() during
the live check, because it raises ERROR if the server is not in the upgrade. The
result would be used only when not in the live check mode, so it's OK to skip.
Also, some comments were slightly reworded.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

Attachment Content-Type Size
v39-0001-pg_upgrade-Allow-to-replicate-logical-replicati.patch application/octet-stream 50.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-09-19 06:19:29 Re: pg_upgrade and logical replication
Previous Message Sergey Sergey 2023-09-19 06:01:09 Re: [PATCH] fastpacth-locks compile time options