Re: Libpq support to connect to standby server as priority - Mailing list pgsql-hackers

From Alvaro Herrera from 2ndQuadrant
Subject Re: Libpq support to connect to standby server as priority
Date
Msg-id 20190910160529.GA11336@alvherre.pgsql
Whole thread Raw
In response to Re: Libpq support to connect to standby server as priority  (Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>)
Responses RE: Libpq support to connect to standby server as priority
List pgsql-hackers
On 2019-Sep-09, Alvaro Herrera from 2ndQuadrant wrote:

> Question about 0001.  In the CONNECTION_SETENV state, you end by falling
> through to the CONNECTION_CHECK_TARGET case; but in that switch it seems
> a bit unnatural to do that.  I think doing "goto keep_trying" is another
> way of doing the same thing, but more in line with what every other
> piece of code does.

Appears to work.  Pushed like that.

Testing protocol version 2 is difficult!  Almost every single test fails
because of error messages being reported differently; and streaming
replication (incl. pg_basebackup) doesn't work at all because it's not
possible to establish replication connections.  Manual inspection shows
it behaves correctly.

Remaining patchset attached (per my count it's v13 of your patchset.
Please use "git format-patch -v14" and so on when posting patches).  I
stripped the doc change from 0001 (unchanged) because I found it hard to
justify on its own, and it has a couple of grammatical mistakes.  I
think we should merge one half of it with each of the other two patches
where the changes are introduced (0003 and 0004).  I'm not convinced
that we need 0004-0006 to be separate commits.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Move user options to the end of the command in pg_upgrade
Next
From: Alvaro Herrera from 2ndQuadrant
Date:
Subject: Re: Useless code in RelationCacheInitializePhase3