Re: Libpq support to connect to standby server as priority

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Libpq support to connect to standby server as priority
Дата
Msg-id 1531752143.2534.60.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Libpq support to connect to standby server as priority  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: Libpq support to connect to standby server as priority  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список pgsql-hackers
Haribabu Kommi wrote:
> > On Wed, Jul 4, 2018 at 11:14 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> > > Haribabu Kommi wrote:
> > >  
> > > - I think the construction with "read_write_host_index" makes the code even more
> > >   complicated than it already is.
> > > 
> > >   What about keeping the first successful connection open and storing it in a
> > >   variable if we are in "prefer-read" mode.
> > >   If we get the read-only connection we desire, close that cached connection,
> > >   otherwise use it.
> > 
> > Even if we add a variable to cache the connection, I don't think the logic of checking
> > the next host for the read-only host logic may not change, but the extra connection
> > request to the read-write host again will be removed.
> 
> I evaluated your suggestion of caching the connection and reuse it when there is no
> read only server doesn't find, but I am thinking that it will add more complexity and also
> the connection to the other servers delays, the cached connection may be closed by
> the server also because of timeout.
> 
> I feel the extra time during connection may be fine, if user is preferring the prefer-read
> mode, instead of adding more complexity in handling the cached connection? 
> 
> comments?

I tested the new patch, and it works as expected.

I don't think that time-out of the cached session is a valid concern, because that
would have to be a really short timeout.
On the other hand, establishing the connection twice (first to check if it is read-only,
then again because no read-only connection is found) can be quite costly.

But that is a matter of debate, as is the readability of the code.

Since I don't think I can contribute more to this patch, I'll mark it as
ready for committer.

Yours,
Laurenz Albe


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: GiST VACUUM