Re: Patch: Implement failover on libpq connect level.
От | Victor Wagner |
---|---|
Тема | Re: Patch: Implement failover on libpq connect level. |
Дата | |
Msg-id | 20151015070740.GA15844@wagner.pp.ru обсуждение исходный текст |
Ответ на | Re: Patch: Implement failover on libpq connect level. ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>) |
Список | pgsql-hackers |
On 2015.10.14 at 14:47:46 +0200, Shulgin, Oleksandr wrote: > > So what exactly would happen with this command: PGHOST=host1 psql -h host2 > > Or this one: PGHOST=host1 psql host=host2 The right thing - value of the PGHOST environment variable is ignored, and explicitely specified host is used. > What about service files? Oops, I've missed something here. Multiple host lines in the service file do not produce list of alternate hosts. I'll address this case in the next version of patch. However, comma-separated list of host in the one host string in the service file works. > > trying postgresql://[::1]:12345/db > -dbname='db' host='::1' port='12345' (inet) > +dbname='db' host='[::1]:12345' (inet) > > Such a change doesn't look really nice to me. Really, any alternative would be worse. Only alternative I can imagine is to replace pghost field in the PGConn structure by array or linked list of structures with host and port fields. Now I decided to keep such array local to connectDBStart function, and store list of host-port pair as string. It takes some CPU cycles to reparse this list each time when reconnection is needed, but this is negligible compared with DNS resolution of each host name. And we cannot avoid repeated DNS resolution, because we have to take into account possibility of DNS-based failover. > > 2. Url with colon but no port number after the host no more considered > > valid. > > > > We could live with that, but is there a good reason for backward > compatibility break in this case? Because we can. Really, I don't see any useful semantic of host with colon at the end. Null host name with colon and port have useful semantic (if there is just one host in the connect string), so it kept as it was. In the old version of connection-string parsing code stripping lone colon of the host name was done by generic code (because port number have gone to another variable anyway). Now handling of lone colon is special case, because we just check syntax of host-port pair list. And I have to choose how to handle it - either complain or silently strip it away. Complaining was similier. We compute port number and check if it is between 1 and 65535. Zero-length port number is not integer between 1 and 65535. > -- > Alex -- Victor Wagner <vitus@wagner.pp.ru>
В списке pgsql-hackers по дате отправления: