On 24 January 2016 at 15:30, Thom Brown <t...@linux.com> wrote: > 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.
Actually, the same goes for the HOST variable, which is currently showing the list of hosts:ports. Output of \set variables without patch: HOST = '127.0.0.1' PORT = '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' And with patch: HOST = '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' PORT = '5488' They're both wrong, but I'm hoping we can just show the right information here. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers