On 23 January 2016 at 03:32, Thom Brown <t...@linux.com> wrote: > On 22 January 2016 at 19:30, Victor Wagner <vi...@wagner.pp.ru> wrote: >> On Tue, 19 Jan 2016 14:34:54 +0000 >> Thom Brown <t...@linux.com> wrote: >> >>> >>> The segfault issue I originally reported now appears to be resolved. >>> >>> But now I have another one: >>> >>> psql >>> 'postgresql://thom@127.0.0.1:5530,127.0.0.1:5531,127.0.0.1:5532,127.0.0.1:5533/postgres?hostorder=random&readonly=1&failover_timeout=5' >>> -c 'show port' >> >> Here is new version of the patch. Now I've reworked hostorder=random and >> it seems to work as well as sequential. failover_timeout works too. >> I've also found a case when attempt to connect fail when receiving >> FATAL message from server which is not properly up yet. So, it is fixed >> too. >> >> Addititonally, error messages from all failed connect attempts are not >> accumulated now. Only last one is returned. > > I can't connect to a standby with the patch applied: > > thom@swift:~/Development/test$ psql -p 5531 postgres > psql: thom@swift:~/Development/test$ > > No error message, nothing in the logs. I find this is the case with > any standby, but doesn't affect primaries. > > So this has broken existing functionality somewhere.
Okay, I've tested this again with additional logging. Again, I'm just running "psql -p 5531 postgres", which connects to a standby. This immediately exits psql, and the logs show: 2016-01-24 15:04:59.879 GMT - [unknown] - [unknown] LOG: 00000: connection received: host=[local] 2016-01-24 15:04:59.879 GMT - [unknown] - [unknown] LOCATION: BackendInitialize, postmaster.c:4081 2016-01-24 15:04:59.880 GMT - thom - postgres LOG: 00000: connection authorized: user=thom database=postgres 2016-01-24 15:04:59.880 GMT - thom - postgres LOCATION: PerformAuthentication, postinit.c:272 2016-01-24 15:04:59.886 GMT - thom - postgres LOG: 00000: statement: SELECT pg_catalog.pg_is_in_recovery() 2016-01-24 15:04:59.886 GMT - thom - postgres LOCATION: exec_simple_query, postgres.c:935 2016-01-24 15:04:59.886 GMT - thom - postgres LOG: 00000: duration: 0.583 ms 2016-01-24 15:04:59.886 GMT - thom - postgres LOCATION: exec_simple_query, postgres.c:1164 2016-01-24 15:04:59.886 GMT - thom - postgres LOG: 00000: disconnection: session time: 0:00:00.007 user=thom database=postgres host=[local] 2016-01-24 15:04:59.886 GMT - thom - postgres LOCATION: log_disconnections, postgres.c:4458 This shouldn't be checking whether it's a standby. I also noticed that with: psql 'postgresql://thom@127.0.0.1:5530,127.0.0.1:5531,127.0.0.1:5532,127.0.0.1:5533,127.0.0.1:5534,127.0.0.1:5535/postgres?hostorder=random&readonly=1' -c 'show port' The standby at port 5533 shows in the logs that it's checking whether it's a standby when it happens to hit it. Shouldn't this be unnecessary if we've set "readonly" to 1? The result of the query doesn't appear to be useful for anything. Another thing I've noticed is that the PORT variable (shown by \set) always shows PGPORT, but I expect it to equal the port of whichever host we successfully connected to. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
