Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

> 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