Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby"GUC pseudo-variable.
От | Tsunakawa, Takayuki |
---|---|
Тема | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby"GUC pseudo-variable. |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F6FCECC@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUCpseudo-variable. |
Список | pgsql-hackers |
From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Craig Ringer > On 13 April 2017 at 14:59, Tsunakawa, Takayuki > <tsunakawa.takay@jp.fujitsu.com> wrote: > > > 2. Make transaction_read_only GUC_REPORT This is to avoid the added > > round-trip by SHOW command. It also benefits client apps that want to > know when the server gets promoted? And this may simplify the libpq code. > > I don't understand yet why we need to provide this feature for older servers > by using SHOW. Those who are already using <= 9.6 in production completed > the system or application, and their business is running. Why would they > want to just replace libpq and use this feature? > > I think "transaction_read_only" is a bit confusing for something we're > expecting to change under us. > > To me, a "read only" xact is one created with > > BEGIN READ ONLY TRANSACTION; > > .... which I would not expect to become read/write under me, since I > explicitly asked for read-only. > > It's more like "session read only" that we're interested in IMO. I confirmed that the attached patch successfully provides: * target_session_attrs=read-only * If the server is >= 10, avoid the round-trip for SHOW transaction_read_only. For this, I added a GUC_REPORT variable session_read_only which indicates the session's default read-only status. The characteristicsare: * It cannot be changed directly by the user (postgresql.conf, SET, etc.) * Its value is the same as default_transaction_read_only when not in recovery. * Its value is false during recovery. Could you include this in PG 10? I think these are necessary as the bottom line to meet the average expectation of users(please don't ask me what's the average; the main reasons are that PostgreSQL provides hot standby, PgJDBC enables connectionto the standby (targetServerType=slave), and PostgreSQL emphasizes performance.) Ideally, I wanted to add otherfeatures of PgJDBC (e.g. targetServerType=preferSlave), but I thought this is the limit not to endanger the qualityof the final release. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: