Hello,
The PGresult structure returned on COPY ... FROM provides a handful of
information (https://www.postgresql.org/docs/13/libpq-copy.html):
number of fields expected and whether they are binary or not.
However it doesn't provide the types expected. For binary copy the
exact type is important:
Hello,
I am designing and implementing a connection pool for psycopg3 [1][2].
Some of the inspiration is coming from HikariCP [3], a Java connection
pool.
One of the HikariCP configuration parameters is "maxLifetime", whose
description is: "This property controls the maximum lifetime of a
connect
On Sun, 21 Feb 2021 at 19:12, Pavel Stehule wrote:
> I have very strong experience - it is very useful.
On Sun, 21 Feb 2021 at 19:26, Stephen Frost wrote:
> Short answer- yes.
Sounds good. Thank you very much for your insight!
-- Daniele
>From psql/help.c
/*
* Keep this line count in sync with the number of lines printed below!
* Use "psql --help=variables | wc" to count correctly; but notice that
* Windows builds currently print one more line than non-Windows builds.
* Using the larger number is fine.
*/
Hello,
We are aware that, using async connection functions (`PQconnectStart`,
`PQconnectPoll`), the `connect_timeout` parameter is not supported;
this is documented at
https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PQCONNECTSTARTPARAMS
"""
The connect_timeout connection paramete
On Wed, 25 Oct 2023 at 17:35, Jelte Fennema wrote:
> You should implement load_balance_hosts=random though
> by randomizing your hosts list.
Good catch. So it seems that, if someone wants to build an equivalent
an async version of PQconnectdb, they need to handle on their own:
- connect_timeout
On Wed, 25 Oct 2023 at 17:35, Jelte Fennema wrote:
> Another approach is to use tcp_user_timeout instead of connect_timeout
> to skip non-responsive hosts. It's not completely equivalent though to
> connection_timeout though, since it also applies when the connection
> is actually being used. Als
On Thu, 26 Oct 2023, 00:10 Jelte Fennema, wrote:
> On Wed, 25 Oct 2023 at 18:54, Daniele Varrazzo
> wrote:
> > - connect_timeout
> > - multiple host, hostaddr, port
> > - load_balance_hosts=random
> >
> > Does this list sound complete?
>
> I think you&#
Hello,
The operator `IS NULL` doesn't work if the argument has unknown type.
In psycopg 3:
>>> conn.execute("select %s is null", ['foo']).fetchone()
IndeterminateDatatype: could not determine data type of parameter $1
This can get in the way of using the unknown type for strings (but
spe
Hello,
a Psycopg 3 user has tested what boils down pretty much to a
"generate_series(100K)" and has reported a 100x difference between
fetching it normally and in single-row mode. I have repeated the test
myself and I have found a 50x difference (the OP doesn't specify which
platform is using, min
On Sun, 1 May 2022 at 23:12, Tom Lane wrote:
> The usual expectation is that you call PQconsumeInput to get rid of
> a read-ready condition on the socket. If you don't have a poll() or
> select() or the like in the loop, you might be wasting a lot of
> pointless recvfrom calls. You definitely d
Hello,
in psycopg 3 we are currently using PQexecParams - although with no
params - to send COPY commands. The reason is mostly to avoid people
to send COPY together with other statements. Especially if other
operations are chained after COPY: we would only notice them after
copy is finished. Data
On Wed, 12 Jun 2024 at 18:08, Jelte Fennema-Nio wrote:
>
> On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote:
> > > The OAuth pytest suite makes extensive use of
> > > - psycopg, to easily drive libpq;
> >
> > That's probably not going to fly. It introduces painful circular
> > dependencies
> >
On Wed, 12 Jun 2024 at 19:30, Daniel Gustafsson wrote:
> I might be missing something obvious, but if we use a third-party libpq driver
> in the testsuite doesn't that imply that a patch adding net new functionality
> to libpq also need to add it to the driver in order to write the tests? I'm
>
On Sat, 20 May 2023 at 00:01, Jacob Champion wrote:
> - Some clients in the wild (psycopg2/psycopg) suppress all notifications
> during PQconnectPoll().
If there is anything we can improve in psycopg please reach out.
-- Daniele
py the
default port on 'conn->connhost[conn->whichhost].port' if the
connection is successful (or even before attempting connection, as to
be able to return the port we tried)?
Cheers
-- Daniele
From be3a051e8f39ad504cd22e22e80178d57949b7d9 Mon Sep 17 00:00:00 2001
From: Daniele Varrazzo
On Thu, 8 May 2025 at 18:58, Daniele Varrazzo
wrote:
> I have prepared a patch, which is attached, to fix the issue. However
> the patch returns the default port in case of no info in
> 'conn->connhost'.
Ah, of course this is wrong if the PGPORT env var is set and
find attached a new patch that doesn't change the behaviour and
just makes sure to not return NULL in case no info is available in
'conn->connhost'.
Cheers
-- Daniele
From ecd3063613a44309583e553db4485cfa55df34a9 Mon Sep 17 00:00:00 2001
From: Daniele Varrazzo
Date: Thu, 8 May 2
18 matches
Mail list logo
