Horton

Re: display hot standby state in psql prompt

Jim Jones <jim.jones@uni-muenster.de>

View thread
From: Jim Jones <jim.jones@uni-muenster.de>
To: Andreas Karlsson <andreas@proxel.se>, Nathan Bossart <nathandbossart@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Srinath Reddy Sadipiralla <srinath2133@gmail.com>, Greg Sabino Mullane <htamfids@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Chao Li <li.evan.chao@gmail.com>
Date: 2025-11-08T10:21:32Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. psql: Add %i prompt escape to indicate hot standby status.

  2. Mark search_path as GUC_REPORT

Hi Andreas

On 08/11/2025 09:57, Andreas Karlsson wrote:
> I am not a fan at all of introducing running a query when calculating
> the prompt. Imagine if there are network issues or otherwise and in
> general I imagine that the prompt can send a query would be highly
> surprising to most users.


I was unable to find a less invasive way to make it work. Initially we
thought about setting transaction_read_only as GUC_REPORT, but we got
concerned about the implicit overhead.


> I personally lean towards that maybe we should keep it simple and go
> back to the origins of the patch which just tried to show if it is a
> standby or not given how complex it is to tell that we are in read-only
> or not. The alternative would be to update the protocol so the client if
> informed if a transaction is read-only or not but I do not think it
> would be possible to convince people to update the protocol just for
> psql. Maybe if some connection pooler would also be interest but I am
> not sure what they would need this for.


If we decide to not consider transaction_read_only for this feature, I
guess we should prevent the prompt to show anything if inside of a
transaction block. Simply ignoring it and showing a potentially wrong
status wouldn't be a good idea.

What do you guys think?

Thanks!

Best, Jim