BUG #18663: synchronous_standby_names vs synchronous_commit vs pg_stat_replication

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: asphator(at)gmail(dot)com
Subject: BUG #18663: synchronous_standby_names vs synchronous_commit vs pg_stat_replication
Date: 2024-10-18 14:48:08
Message-ID: 18663-b02f75cb919f1b60@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: 18663
Logged by: Asphator
Email address: asphator(at)gmail(dot)com
PostgreSQL version: 15.7
Operating system: RHEL7+
Description:

Hello

I would like to raise 2 issues:
- documentation issue
- pg_stat_replication view issue in a very specific use case

1. Documentation
Regarding parameter synchronous_standby_names, I did not manage to find
anything in documentation preventing from setting value 0. The only thing
I've found is a comment in a commit of 2016. Would be nice to mention in
documentation that value must be a "positive" integer.

2. Synchronous_mode
Seems to me that quorum mode is only effective when both conditions below
are met:
- synchronous_commit is set either to "on / remote_write", "remote_flush" or
"remote_apply"
- synchronous_standby_names is set to "ANY N (....)", with N >= 1 and (...)
a list of slaves

According to the documentation, setting synchronous_commit value either to
local or off, meaning we do not care at all about any kind of ACK from any
slave), should thus be enough to disable synchronous mode.

So if you do so, event if you let (or better say forget, because we agree
it's non consistent) parameter synchronous_standby_names with value "ANY N
(...)", we are supposed to be in asynchronous mode.
Still, view pg_stat_replication shows up "quorum" which is (worse of) a
non-sense. Should show up "async" to me.
Or am i wrong here ?
Same as for 1, could that be less ambiguous in documentation whether quorum
preempts on synchronous_mode and that would explain, or if it's not supposed
to, to fix this in the pg_stat_replication view ?

Kind Regards
Arpad

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-10-18 17:22:05 Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
Previous Message Alexander Lakhin 2024-10-18 08:00:00 Re: BUG #18658: Assert in SerialAdd() due to race condition