Re: display hot standby state in psql prompt

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Subject: Re: display hot standby state in psql prompt
Date: 2025-11-10 08:14:49
Message-ID: 69fe434e-d7b0-42f1-9368-cc76de7f446f@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/11/2025 08:30, Fujii Masao wrote:
> If the main goal of this feature is to help users easily determine
> whether they're connected to a primary or a standby,
> seems simply showing whether the server is in hot standby
> should be sufficient. I'm not sure how useful it would be in practice
> to show information based on default_transaction_read_only or
> transaction_read_only.

This "primary" or "standby" approach was actually the initial proposal,
but it evolved after a few reviews. Extending it to use
transaction_read_only and default_transaction_read_only adds real value
to the feature, but doing so requires either:

1. Marking transaction_read_only as GUC_REPORT (controversial and
rejected in the past), or
2. Querying transaction_read_only with SHOW every time the prompt is
displayed within a transaction block (IMO minimal overhead -- but
unconventional?).

Although I lean toward the initial proposal, I can totally live with
either approach, since both would be able to distinguish if a server is
in hot standby or not.

Should we switch back to the initial proposal?

Thanks!

Best, Jim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2025-11-10 08:30:22 Re: contrib/pg_stat_tcpinfo
Previous Message Chao Li 2025-11-10 08:06:36 Improve logical replication usability when tables lack primary keys