On Tue, Sep 12, 2017 at 6:11 PM, Thomas Munro <thomas.mu...@enterprisedb.com > wrote:
> On Wed, Sep 13, 2017 at 3:48 AM, Elvis Pranskevichus <elpr...@gmail.com> > wrote: > > I incorporated those bits into your patch and rebased in onto master. > > Please see attached. > > > > FWIW, I think that mixing the standby status and the default > > transaction writability is suboptimal. They are related, yes, but not > > the same thing. It is possible to have a master cluster in the > > read-only mode, and with this patch it would be impossible to > > distinguish from a hot-standby replica without also polling > > pg_is_in_recovery(), which defeats the purpose of having to do no > > database roundtrips. > > Hi Elvis, > > FYI the recovery test 001_stream_rep.pl fails with this patch applied. > You can see that if you configure with --enable-tap-tests, build and > then cd into src/test/recovery and "make check". > > The latest patch applies cleanly and builds (I am also seeing the failing TAP tests), however, I have a concern. With a single 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_attrs and successfully connect to a server on which read and write operations are permitted. I see this behavior implemented 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?
