Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. |
Дата | |
Msg-id | CA+TgmoaULj0A9JK_cDg63C7d8zZDdr=SiwnyoGfm1VHWA8SuNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby"GUC pseudo-variable. ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.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"GUC pseudo-variable. |
Список | pgsql-hackers |
On Wed, May 24, 2017 at 3:16 AM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > 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. Thecharacteristics are: > > * 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. I've already stated my position on this, which is that: * target_session_attrs=read-only is a perfectly good new feature, but we're past feature freeze, so it's material for v11. * I'm not opposed to adding a GUC_REPORT GUC of some kind, but I see no urgency about that either. The feature works fine as it is. The fact that it could possibly be made to work more efficiently is not a critical bug. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: