BUG #19473: regression error in dblink: another command is already in progress

On Sat, 9 May 2026 at 00:43, PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 19473
Logged by: Oleg Ivanov
Email address: o15611@gmail.com
PostgreSQL version: 18.3
Operating system: Linux
Description:

Testcase:
SELECT * FROM dblink('dbname=postgres user=postgres', $$ select 7; $$ ) as
(col1 int);
SELECT * FROM dblink_connect('connection1', 'host=/var/run/postgresql
port=5432');
SELECT * FROM dblink_send_query('connection1', $$ select 8 from pg_sleep(1);
$$ );
SELECT dblink_is_busy('connection1');
SELECT * FROM dblink_get_result('connection1') as t(col1 int);
--- SELECT dblink_is_busy('connection1');
SELECT * FROM dblink_exec('connection1', $$ CHECKPOINT; $$);
SELECT * FROM dblink_disconnect('connection1');

col1
------
7
(1 row)

dblink_connect
----------------
OK
(1 row)

dblink_send_query
-------------------
1
(1 row)

dblink_is_busy
----------------
1
(1 row)

col1
------
8
(1 row)

ERROR: another command is already in progress
CONTEXT: while executing command on dblink connection named "connection1"
dblink_disconnect
-------------------
OK
(1 row)

There was no error in 16 version. The error appeared in 17 version. It
seems, there is a regression bug.
The workaround is to uncomment a commented statement.

Hi! Thank you for this report, I was able to reproduce this behaviour.
My git bisect shows that first commit where this errors out is d3c5f37

```
commit d3c5f37dd543498cc7c678815d3921823beec9e9 (HEAD)
Author: Noah Misch <noah@leadboat.com>
Date: Mon Jan 8 11:39:56 2024 -0800

Make dblink interruptible, via new libpqsrv APIs.

```

--
Best regards,
Kirill Reshke

On Sat, 9 May 2026 at 01:24, Kirill Reshke <reshkekirill@gmail.com> wrote:

On Sat, 9 May 2026 at 00:43, PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 19473
Logged by: Oleg Ivanov
Email address: o15611@gmail.com
PostgreSQL version: 18.3
Operating system: Linux
Description:

Testcase:
SELECT * FROM dblink('dbname=postgres user=postgres', $$ select 7; $$ ) as
(col1 int);
SELECT * FROM dblink_connect('connection1', 'host=/var/run/postgresql
port=5432');
SELECT * FROM dblink_send_query('connection1', $$ select 8 from pg_sleep(1);
$$ );
SELECT dblink_is_busy('connection1');
SELECT * FROM dblink_get_result('connection1') as t(col1 int);
--- SELECT dblink_is_busy('connection1');
SELECT * FROM dblink_exec('connection1', $$ CHECKPOINT; $$);
SELECT * FROM dblink_disconnect('connection1');

col1
------
7
(1 row)

dblink_connect
----------------
OK
(1 row)

dblink_send_query
-------------------
1
(1 row)

dblink_is_busy
----------------
1
(1 row)

col1
------
8
(1 row)

ERROR: another command is already in progress
CONTEXT: while executing command on dblink connection named "connection1"
dblink_disconnect
-------------------
OK
(1 row)

There was no error in 16 version. The error appeared in 17 version. It
seems, there is a regression bug.
The workaround is to uncomment a commented statement.

Hi! Thank you for this report, I was able to reproduce this behaviour.
My git bisect shows that first commit where this errors out is d3c5f37

```
commit d3c5f37dd543498cc7c678815d3921823beec9e9 (HEAD)
Author: Noah Misch <noah@leadboat.com>
Date: Mon Jan 8 11:39:56 2024 -0800

Make dblink interruptible, via new libpqsrv APIs.

```

So, reason is that dblink_get_result calls dblink_record_internal
which in turn read data with

/* async result retrieval, do it the old way */
PGresult *res = libpqsrv_get_result(conn, dblink_we_get_result);

inside, PQgetResult sets connection state to PGASYNC_READY, and then
reads all messages from this connection but not the RFQ.
this pending RFQ causing issues on any subsequent dblink call with
this connection.

I have this "funny" fix by the way. Obviously this is dumb, but I
think we should do something similar

```
reshke@reshke:~/pg$ git diff
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 19a362526d2..ed3e8023b55 100644
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@@ -812,6 +812,8 @@ dblink_record_internal(FunctionCallInfo fcinfo,
bool is_async)
        }
        PG_END_TRY();

+       Assert(!PQisBusy(conn));
+
        return (Datum) 0;
 }

```

--
Best regards,
Kirill Reshke

On Sat, May 9, 2026 at 4:43 AM PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 19473
Logged by: Oleg Ivanov
Email address: o15611@gmail.com
PostgreSQL version: 18.3
Operating system: Linux
Description:

Testcase:
SELECT * FROM dblink('dbname=postgres user=postgres', $$ select 7; $$ ) as
(col1 int);
SELECT * FROM dblink_connect('connection1', 'host=/var/run/postgresql
port=5432');
SELECT * FROM dblink_send_query('connection1', $$ select 8 from pg_sleep(1);
$$ );
SELECT dblink_is_busy('connection1');
SELECT * FROM dblink_get_result('connection1') as t(col1 int);
--- SELECT dblink_is_busy('connection1');
SELECT * FROM dblink_exec('connection1', $$ CHECKPOINT; $$);
SELECT * FROM dblink_disconnect('connection1');

col1
------
7
(1 row)

dblink_connect
----------------
OK
(1 row)

dblink_send_query
-------------------
1
(1 row)

dblink_is_busy
----------------
1
(1 row)

col1
------
8
(1 row)

ERROR: another command is already in progress
CONTEXT: while executing command on dblink connection named "connection1"
dblink_disconnect
-------------------
OK
(1 row)

There was no error in 16 version. The error appeared in 17 version. It
seems, there is a regression bug.
The workaround is to uncomment a commented statement.

The documentation for dblink_get_result() notes "It must be called once for
each query sent, and one additional time to obtain an empty set result,
before the connection can be used again". So in your case, it seems that
dblink_get_result() needs to be called one more time before calling
dblink_exec(). If you do that, I think that the error "another command is
already in progress" should not occur. Therefore, this does not seem to be
a bug to me. Thought?

Regards,

--
Fujii Masao

On Tue, 12 May 2026, 18:47 Fujii Masao, <masao.fujii@gmail.com> wrote:

On Sat, May 9, 2026 at 4:43 AM PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 19473
Logged by: Oleg Ivanov
Email address: o15611@gmail.com
PostgreSQL version: 18.3
Operating system: Linux
Description:

Testcase:
SELECT * FROM dblink('dbname=postgres user=postgres', $$ select 7; $$ )

as

(col1 int);
SELECT * FROM dblink_connect('connection1', 'host=/var/run/postgresql
port=5432');
SELECT * FROM dblink_send_query('connection1', $$ select 8 from

pg_sleep(1);

$$ );
SELECT dblink_is_busy('connection1');
SELECT * FROM dblink_get_result('connection1') as t(col1 int);
--- SELECT dblink_is_busy('connection1');
SELECT * FROM dblink_exec('connection1', $$ CHECKPOINT; $$);
SELECT * FROM dblink_disconnect('connection1');

col1
------
7
(1 row)

dblink_connect
----------------
OK
(1 row)

dblink_send_query
-------------------
1
(1 row)

dblink_is_busy
----------------
1
(1 row)

col1
------
8
(1 row)

ERROR: another command is already in progress
CONTEXT: while executing command on dblink connection named

"connection1"

dblink_disconnect
-------------------
OK
(1 row)

There was no error in 16 version. The error appeared in 17 version. It
seems, there is a regression bug.
The workaround is to uncomment a commented statement.

The documentation for dblink_get_result() notes "It must be called once for
each query sent, and one additional time to obtain an empty set result,
before the connection can be used again". So in your case, it seems that
dblink_get_result() needs to be called one more time before calling
dblink_exec(). If you do that, I think that the error "another command is
already in progress" should not occur. Therefore, this does not seem to be
a bug to me. Thought?

Regards,

--
Fujii Masao

Doesn't dblink_is_busy violates this doc then? I mean, dblink_is_busy has
side effect of changing connection state. Is this OK?

On Tue, May 12, 2026 at 10:59 PM Kirill Reshke <reshkekirill@gmail.com> wrote:

Doesn't dblink_is_busy violates this doc then? I mean, dblink_is_busy has side effect of changing connection state. Is this OK?

Maybe I'm missing your point...
Could you clarify what actual issue you are concerned about
with that use of dblink_is_busy()?

Regards,

--
Fujii Masao