cluster_name looks like a cosmetic: a label that shows up in ps output so you can tell your three postgres instances apart. On a primary, that’s all it is. On a standby, it can quietly become the name the primary uses to decide whether synchronous replication is satisfied, which is a much bigger job for a parameter most people set and forget.
The default is the empty string, meaning no name and no change to the process title. The context is postmaster, so setting it costs a restart; that’s fine, because this is a label rather than a knob, and you set a label once at provisioning time. It arrived in PostgreSQL 9.5.
With it set, every process belonging to that instance carries the name in its title: postgres: server1: background writer, postgres: server1: walwriter, and so on. Run several clusters on one host and this is the difference between ps output you can actually read and a wall of identical postgres: lines that tell you nothing about which is which. The value is capped at NAMEDATALEN (63 usable characters), and any non-ASCII characters get replaced with question marks, because the process title has to survive whatever encoding disagreements exist between postgresql.conf, your shell, and the databases themselves.
The part that earns the restart is on the replica. Since PostgreSQL 12, if a standby has cluster_name set and its primary_conninfo does not specify an application_name, the cluster name becomes the fallback application name the standby presents when it connects upstream. That’s the name that appears in the primary’s pg_stat_replication.application_name, and it’s the name synchronous_standby_names matches against. So a standby you called replica_west for the benefit of ps is also announcing itself as replica_west to the primary’s synchronous-replication logic, whether or not you intended the label to do double duty.
This is a tidy way to break synchronous replication without touching anything that looks like replication. Rename a standby’s cluster_name to clean up your process listings, restart, and if the primary’s synchronous_standby_names still lists the old name, the primary no longer has a synchronous standby answering to it. Depending on your configuration that’s either redundancy you’ve silently lost or commits hanging while they wait for confirmation from a standby that will never connect under that name again. The connection between “I tidied up the ps output” and “the primary is now refusing to commit” is not one anybody enjoys discovering at 2 a.m.
So set it. On a primary it’s a free improvement to operational legibility, and the only cost is one restart you were going to schedule anyway. On a standby, set it deliberately and treat it as part of your replication identity, not your ps decoration; or set application_name explicitly in primary_conninfo (see application_name) so the two concerns stop sharing one value. The mistake here is rarely leaving it empty. It’s changing it on a replica without remembering what else is reading it.