Horton

RE: A recent message added to pg_upgade

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

View thread View on postgr.es
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Bharath Rupireddy' <bharath.rupireddyforpostgres@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-30T09:03:24Z
Lists: pgsql-hackers

Attachments

Dear Bharath,

> Will the check_hook approach work correctly?

I tested by using the first version and worked well (rejected). Please see the
log which recorded the output and log. Below lines were copied from server
log and found that max_slot_wal_keep_size must not be >= 0.

```
waiting for server to start....2023-10-30 08:53:32.529 GMT [6903] FATAL:  invalid value for parameter "max_slot_wal_keep_size": 1
 stopped waiting
pg_ctl: could not start serve
```

> I haven't checked that by
> myself, but I see InitializeGUCOptions() getting called before
> IsBinaryUpgrade is set to true and the passed-in config options ('c')
> are parsed.

I thought the key point was that user-defined options are aligned after the "-b".
User-defined options are set after the '-b'  option, so check_hook could work
as we expected. Thought?

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

Commits

  1. Fix the handling of two GUCs during upgrade.

  2. Rework how logirep launchers are stopped during pg_upgrade

  3. Prohibit max_slot_wal_keep_size to value other than -1 during upgrade.

  4. Prevent startup of logical replication launcher during pg_upgrade

  5. Migrate logical slots to the new node during an upgrade.