Date: Wed, 23 Jan 2019 08:56:04 +0200
From: Pavlo Golub <pavlo.golub@cybertec.at>
Message-ID: <1663901278.20190123085604@cybertec.at>
To: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-docs@lists.postgresql.org
Subject: Re: `transaction_read_only` GUC undocumented
In-Reply-To: <20190123061422.GK3873@paquier.xyz>
References: <20190123002536.GC3873@paquier.xyz>
  <18fa8fbf-f5a3-4e4b-b751-8b9da58c117c@email.android.com>
  <20190123055440.GI3873@paquier.xyz> <4210.1548223651@sss.pgh.pa.us>
  <20190123061422.GK3873@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Greetings, Michael.

You wrote 23.01.2019, 8:14:

> On Wed, Jan 23, 2019 at 01:07:31AM -0500, Tom Lane wrote:
>> Michael Paquier <michael@paquier.xyz> writes:
>>> transaction_read_only is listed in src/backend/utils/misc/guc.c, so we
>>> could put a description close to default_transaction_read_only in
>>> config.sgml, except that transaction_read_only sets the current
>>> transaction's read-only status.
>> 
>> Do we really want to document that?  It's not the standard-approved
>> way of making a transaction read-only.

> i'd rather document them clearly rather than letting them around with
> users guessing what they actually do (remember the recent thread about
> replication parameter in connection strings).

Exactly my case. Client sent support request stating that changing
this parameter doesn't work. Of course, he was doing this outside of
transaction. And of course he doesn't find manual reference and was
guessing about it's behavior.

>  By the way, I can see
> that transaction_deferrable and transaction_isolation are not around
> either...

> --
> Michael


-- 
Kind regards,
 Pavlo                          mailto:pavlo.golub@cybertec.at