| 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
| 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 |