Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
От | Daniel Gustafsson |
---|---|
Тема | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. |
Дата | |
Msg-id | 5C470924-91C3-49DB-852A-95924B60B6F5@yesql.se обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
(Michael Paquier <michael.paquier@gmail.com>)
|
Список | pgsql-hackers |
> On 22 Sep 2017, at 18:57, Melanie Plageman <melanieplageman@gmail.com> wrote: > > On Tue, Sep 19, 2017 at 4:15 PM, Melanie Plageman <melanieplageman@gmail.com <mailto:melanieplageman@gmail.com>> wrote: > The latest patch applies cleanly and builds (I am also seeing the failing TAP tests), however, I have a concern. With asingle server set up, when I attempt to make a connection with target_session_attrs=read-write, I get the message > psql: could not make a suitable connection to server "localhost:5432" > Whereas, when I attempt to make a connection with target_session_attrs=read-only, it is successful. > > I might be missing something, but this seems somewhat counter-intuitive. I would expect to specify read-write as target_session_attrsand successfully connect to a server on which read and write operations are permitted. I see this behaviorimplemented in src/interfaces/libpq/fe-connect.c > Is there a reason to reject a connection to a primary server when I specify 'read-write'? Is this intentional? > > Hi Elvis, > > Making an assumption about the intended functionality mentioned above, I swapped the 'not' to the following lines of src/interfaces/libpq/fe-connect.c~ line 3005 > > if (conn->target_session_attrs != NULL && > ((strcmp(conn->target_session_attrs, "read-write") == 0 && conn->session_read_only) || > (strcmp(conn->target_session_attrs, "read-only") == 0 && !conn->session_read_only))) > > I rebased and built with this change locally. > The review below is based on the patch with that change. > > Also, the following comment has what looks like a copy-paste error and the first line should be deleted > in src/backend/utils/misc/guc.c ~ line 10078 > assign_default_transaction_read_only > > > +assign_default_transaction_read_only(bool newval, void *extra) > ... > + /* > - * We clamp manually-set values to at least 1MB. Since > + * Also set the session read-only parameter. We only need > + * to set the correct value in processes that have database > + * sessions, but there's no mechanism to know that there's > > patch applies cleanly: yes > installcheck: passed > installcheck-world: passed > feature works as expected: yes (details follow) > > With two servers, one configured as the primary and one configured to run in Hot Standby mode, I was able to observe thatthe value of session_read_only changed after triggering failover once the standby server exited recovery > > When attempting to connect to a primary server with target_session_attrs=read-write, I was successful and when attemptingto connect with target_session_attrs=read-only, the connection was closed and the expected message was produced Based on the unaddressed questions raised in this thread, I’m marking this patch Returned with Feedback. Please re-submit a new version of the patch to a future commitfest. cheers ./daniel -- 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 по дате отправления:
Предыдущее
От: Masahiko SawadaДата:
Сообщение: Re: [HACKERS] Transactions involving multiple postgres foreign servers
Следующее
От: Daniel GustafssonДата:
Сообщение: Re: [HACKERS] document and use SPI_result_code_string()