BUG #17904: Inconsistent value of max_worker_processes parameter in the config file and running cluster

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: psadm999(at)gmail(dot)com
Subject: BUG #17904: Inconsistent value of max_worker_processes parameter in the config file and running cluster
Date: 2023-04-19 19:54:38
Message-ID: 17904-05f2c291bab3ffb7@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 17904
Logged by: Pawel
Email address: psadm999(at)gmail(dot)com
PostgreSQL version: 11.19
Operating system: Rocky8
Description:

Hi,
I'd like to report an issue I discovered recently.

Today I noticed very weird behavior when I was setting up PostgreSQL 11.19
cluster with binary replication.
The exact version: "PostgreSQL 11.19 on x86_64-pc-linux-gnu, compiled by gcc
(GCC) 8.5.0 20210514 (Red Hat 8.5.0-16), 64-bit" running on Rocky Linux
8.7.

Basically my primary server is starting with `max_worker_processes = 4`.
Unfortunately the secondary one created with pg_basebackup was not able to
start complaining:

"FATAL: hot standby is not possible because max_worker_processes = 4 is a
lower setting than on the master server (its value was 8)."

I double checked the configs on the primary (they were correct, ie.
max_worker_processes = 4, didn't forgot to remove the comment :) ). I
restarted the cluster, etc. Still the primary was showing
max_worker_processes=4 in psql but the secondary was complaining as before,
saying:
"FATAL: hot standby is not possible because max_worker_processes = 4 is a
lower setting than on the master server (its value was 8).".

My final attempt was to put the value in single quotes and after that it
worked - primary was showing 4 and the secondary managed to connect with the
same settings.

The documentation reg. postgresql.conf file states:
"Numeric (integer and floating point): A decimal point is permitted only for
floating-point parameters. Do not use thousands separators. Quotes are not
required."

It looks that the quotes actually are required, or it's a bug? This
particular case shows the parameter value without quotes is automatically
set to default value of 8, while the dbas see the value from the
configuration file.

BR,
Pawel

Browse pgsql-bugs by date

  From Date Subject
Next Message Jeff Davis 2023-04-19 20:31:17 Re: Assert failure with ICU support
Previous Message Pavel Borisov 2023-04-19 18:56:52 Re: BUG #17847: Unaligned memory access in ltree_gist