From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: Implement failover on libpq connect level. |
Date: | 2016-01-19 14:34:54 |
Message-ID: | CAA-aLv4ddFHXA0BHZz-dLXJJNVfhj8JURDm77izZCO8UaM1oVg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
On 21 December 2015 at 14:50, Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> wrote:
> On Mon, 21 Dec 2015 17:18:37 +0300
> Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
>
>> Sorry, but there is something wrong with your patch:
>> % patch -p1 -C < ~/Downloads/libpq-failover-5.patch
>
> Really, somehow broken version of the patch got into message.
>
> Here is correct one.
The segfault issue I originally reported now appears to be resolved.
But now I have another one:
psql 'postgresql://thom(at)127(dot)0(dot)0(dot)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'
Segmentation fault
This is where no nodes are available. If I remove hostorder=random,
or replace it with hostorder=sequential, it doesn't segfault.
However, it then tries to connect to PGHOST on PGPORT repeatedly, even
if I bring up one of the nodes it should be looking for. Not only
this, but it seems to do it forever if failover_timeout is greater
than 0.
Thom
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-01-19 14:38:42 | Re: COPY (... tab completion |
Previous Message | Craig Ringer | 2016-01-19 14:26:46 | Re: Re: pglogical_output - a general purpose logical decoding output plugin |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-01-19 18:01:47 | Re: Re: [JDBC] 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102 |
Previous Message | Dave Cramer | 2016-01-19 14:32:49 | Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435) |