Re: Designing a better connection pool for psycopg3 - Mailing list psycopg

From Magnus Hagander
Subject Re: Designing a better connection pool for psycopg3
Date
Msg-id CABUevEy7xvvmBjTLGuQ5R3nETK5SURsS1UswgNT9iCF0VUJZpg@mail.gmail.com
Whole thread Raw
In response to Re: Designing a better connection pool for psycopg3  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List psycopg
On Mon, Jan 18, 2021 at 4:12 PM Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
>
> On Mon, 18 Jan 2021 at 15:39, Magnus Hagander <magnus@hagander.net> wrote:
> >
> > On Mon, Jan 18, 2021 at 3:29 PM Daniele Varrazzo
> > <daniele.varrazzo@gmail.com> wrote:
>
> > > I'm trying to imagine what happens in a case such as a network
> > > partition or reconfiguration, and the app server doesn't see the
> > > database anymore. This node is arguably broken.
> >
> > Only if this is the *only* thing it does.
> >
> > It might still be able to reach other services on other nodes. Other
> > databases. Heck, even other database son the same node if it was a
> > config error.
>
> In your opinion (and Karsten's, if he'd like to chip in), what should
> happen on program start? Is attempting to create a new connection in
> the main thread, and throwing an exception if failing to do so, a
> reasonable behaviour?

Yes, I think that's perfectly reasonable.

The application is always going to have to be ready to get an
exception on the call to get a connection out of the pool. If it cares
about the "early startup failure", it should just try to grab a
connection immediately on startup and will then notice if it fails.


-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



psycopg by date:

Previous
From: Karsten Hilbert
Date:
Subject: Re: Designing a better connection pool for psycopg3
Next
From: Aryeh Leib Taurog
Date:
Subject: pgcopy 1.5.0 release announcement