On Wed, Sep 13, 2017 at 3:48 AM, Elvis Pranskevichus <elprans@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?