| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> | 
|---|---|
| To: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> | 
| Cc: | 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> | 
| Subject: | Re: display hot standby state in psql prompt | 
| Date: | 2025-10-30 03:42:27 | 
| Message-ID: | CAHGQGwEA_F=QL_5fYp7ucO_MiajLuXBZdD2wSZVnW6Vy0KTU3A@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Tue, Oct 28, 2025 at 8:03 PM Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> wrote:
>
>
>
> On 28/10/2025 00:55, Fujii Masao wrote:
> > If we mark transaction_read_only as GUC_REPORT, wouldn't the reset value
> > be sent automatically at the end of the transaction? It seems like we wouldn't
> > need any new mechanism for that. However, the downside might be that
> > more ParameterStatus messages would be sent, potentially adding overhead.
>
>
> I tried that, but simply marking it as GUC_REPORT does not reset the
> variable when the transaction ends.
>
> == guc_parameters.dat ==
>
> { name => 'transaction_read_only', type => 'bool', context =>
> 'PGC_USERSET', group => 'CLIENT_CONN_STATEMENT',
>   short_desc => 'Sets the current transaction\'s read-only status.',
>   flags => 'GUC_NO_RESET | GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE |
> GUC_DISALLOW_IN_FILE | GUC_REPORT',
>   variable => 'XactReadOnly',
>   boot_val => 'false',
>   check_hook => 'check_transaction_read_only',
> },
>
> == prompt.c ==
>
> ...
> const char *hs = PQparameterStatus(pset.db, "in_hot_standby");
> const char *ro = PQparameterStatus(pset.db,
> "default_transaction_read_only");
> const char *tr = PQparameterStatus(pset.db, "transaction_read_only");
>
> if (!hs || !ro || !tr)
>         strlcpy(buf, _("unknown"), sizeof(buf));
> else if (strcmp(hs, "on") == 0 || strcmp(ro, "on") == 0 || strcmp(tr,
> "on") == 0)
>         strlcpy(buf, "read-only", sizeof(buf));
> else
>         strlcpy(buf, "read/write", sizeof(buf));
>
> ...
>
> == test ==
>
> psql (19devel)
> Type "help" for help.
>
> postgres=# \set PROMPT1 '[%i] # '
> [read/write] # BEGIN;
> BEGIN
> [read/write] # SET transaction_read_only TO on;
> SET
> [read-only] # END;
> COMMIT
> [read-only] # SHOW transaction_read_only;
>  transaction_read_only
> -----------------------
>  off
> (1 row)
>
> [read-only] #
>
>
> So I assumed that the reset happens during transaction cleanup, which
> might not send parameter status updates.
>
> Am I missing something?
No, you're right. I mistakenly thought marking it as GUC_REPORT was enough
since BEGIN READ ONLY + COMMIT/ROLLBACK worked as expected,
but I overlooked the SET transaction_read_only + COMMIT case where
it doesn't. Sorry for the noise.
Regards,
-- 
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2025-10-30 03:45:32 | Re: tuple radix sort | 
| Previous Message | David Rowley | 2025-10-30 03:41:56 | Re: another autovacuum scheduling thread |