Previously, a conn.Write would simply unlock pgconn, leaving the
connection as Idle and reusable while the multiResultReader would be
closed. From this state, calling multiResultReader.Close won't try to
receiveMessage and thus won't unwatch and close the connection since it
is already closed. This leaves the connection "open" and the next time
it's used, a "Watch already in progress" panic could be triggered.
This patch fixes the issue by unwatching and closing the connection on a
batch write error. The same was done on Sync.Encode error even if the
path is unreachable as Sync.Error never returns an error.
A single Connect("connstring") may actually make multiple connection
requests due to TLS or HA configuration. Previously, when all attempts
failed only the last error was returned. This could be confusing.
Now details of all failed attempts are included.
For example, the following connection string:
host=localhost,127.0.0.1,foo.invalid port=1,2,3
Will now return an error like the following:
failed to connect to `user=postgres database=pgx_test`:
lookup foo.invalid: no such host
[::1]:1 (localhost): dial error: dial tcp [::1]:1: connect: connection refused
127.0.0.1:1 (localhost): dial error: dial tcp 127.0.0.1:1: connect: connection refused
127.0.0.1:2 (127.0.0.1): dial error: dial tcp 127.0.0.1:2: connect: connection refused
https://github.com/jackc/pgx/issues/1929
The PostgreSQL server will reject messages greater than ~1 GB anyway.
However, worse than that is that a message that is larger than 4 GB
could wrap the 32-bit integer message size and be interpreted by the
server as multiple messages. This could allow a malicious client to
inject arbitrary protocol messages.
https://github.com/jackc/pgx/security/advisories/GHSA-mrww-27vc-gghv
Otherwise, it might be possible to panic when closing the pipeline if it
tries to read a connection that should be closed but still has a fatal
error on the wire.
https://github.com/jackc/pgx/issues/1920
OnPGError is called on every error response received from Postgres and can
be used to close connections on specific errors. Defaults to closing on
FATAL-severity errors.
Fixes#1803
The context timeouts for tests are designed to give a better error
message when something hangs rather than the test just timing out.
Unfortunately, the potato CI frequently has some test or another
randomly take a long time. While the increased times are somewhat less
than optimal on a real computer, hopefully this will solve the
flickering CI.
on Windows connecting on a closed port takes about 2 seconds.
You can test with something like this
start := time.Now()
_, err := d.DialContext(context.Background(), "tcp", "127.0.0.1:1")
fmt.Printf("finished, time %s, err: %v\n", time.Since(start), err)
This seems by design
https://groups.google.com/g/comp.os.ms-windows.programmer.win32/c/jV6kRVY3BqM
Generally TestConnectWithFallback takes about 8-9 seconds on Windows.
Increase timeout to avoid random failures under load
Tests should timeout in a reasonable time if something is stuck. In
particular this is important when testing deadlock conditions such as
can occur with the copy protocol if both the client and the server are
blocked writing until the other side does a read.
ioutil.TempFile: Deprecated: As of Go 1.17, this function simply calls os.CreateTemp.
ioutil.ReadFile: Deprecated: As of Go 1.16, this function simply calls os.ReadFile.
CopyFrom had to create a prepared statement to get the OIDs of the data
types that were going to be copied into the table. Every COPY operation
required an extra round trips to retrieve the type information. There
was no way to customize this behavior.
By leveraging the QueryExecMode feature, like in `Conn.Query`, users can
specify if they want to cache the prepared statements, execute
them on every request (like the old behavior), or bypass the prepared
statement relying on the pgtype.Map to get the type information.
The `QueryExecMode` behave exactly like in `Conn.Query` in the way the
data type OIDs are fetched, meaning that:
- `QueryExecModeCacheStatement`: caches the statement.
- `QueryExecModeCacheDescribe`: caches the statement and assumes they do
not change.
- `QueryExecModeDescribeExec`: gets the statement description on every
execution. This is like to the old behavior of `CopyFrom`.
- `QueryExecModeExec` and `QueryExecModeSimpleProtocol`: maintain the
same behavior as before, which is the same as `QueryExecModeDescribeExec`.
It will keep getting the statement description on every execution
The `QueryExecMode` can only be set via
`ConnConfig.DefaultQueryExecMode`, unlike `Conn.Query` there's no
support for specifying the `QueryExecMode` via optional arguments
in the function signature.
CockroachDB added support for COPY in version 20.2.
https://www.cockroachlabs.com/docs/v20.2/copy-from
There are some limitations on the implementation, that's why not all the
existing tests were enabled.
Instead of using pgproto3.FieldDescription through pgconn and pgx. This
lets the lowest level pgproto3 still be as memory efficient as possible.
https://github.com/jackc/pgx/pull/1281
Anthonin Bonnefoy
Jack Christensen
zenkovev
Oleksandr Redko
zenkovev
James Hartig
Simon Paredes
Anton Levakin
Ville Skyttä
Nicola Murino
Alexey Palazhchenko
Mark Chambers
Alejandro Do Nascimento Mora
Tommy Reilly