Обсуждение: BUG #18966: Invalid SQL queries hang indefinitely until server restart

The following bug has been logged on the website:

Bug reference:      18966
Logged by:          Jérémy S
Email address:      jeremy.spriet@gmail.com
PostgreSQL version: 16.9
Operating system:   Docker debian
Description:

Hello,
I’m running PostgreSQL 16.9 in Docker (PostgreSQL 16.9 (Debian
16.9-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc 12.2.0, 64-bit),
and intermittently observe that invalid SQL queries hang indefinitely
instead of immediately returning an error.
Valid queries continue to work normally and return results right away.
I usually issue statements via a Python client library, but when the issue
occurs, I see the same blocking behavior connecting directly with psql—the
session simply stalls and never reports syntax errors, “relation does not
exist,” or any other error.
Only a full restart of the Docker container unblocks all sessions.
This has happened 2–3 times over the past six months, but I haven’t been
able to reproduce it on demand.
When a query hangs, even running: SELECT pg_cancel_backend(pid); or SELECT
pg_terminate_backend(pid); does not unblock it. Only restarting the
container helps.
Does anyone have ideas on what could be causing this behavior?
My postgresql.conf:
listen_addresses = '*'
max_prepared_transactions = 0
shared_buffers = 2000MB
temp_buffers = 8MB
max_connections = 5010
superuser_reserved_connections = 2
shared_preload_libraries = 'timescaledb,pg_cron,pg_stat_statements'
cron.database_name = 'db1'
pg_stat_statements.max = 5000
pg_stat_statements.track = top
Thanks!

PG Bug reporting form <noreply@postgresql.org> writes:
> I’m running PostgreSQL 16.9 in Docker (PostgreSQL 16.9 (Debian
> 16.9-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc 12.2.0, 64-bit),
> and intermittently observe that invalid SQL queries hang indefinitely
> instead of immediately returning an error.
> Valid queries continue to work normally and return results right away.

What exactly is "invalid" about the troublesome queries?  What does
pg_stat_activity show them as doing?  When the problem is occurring,
can you run EXPLAIN (*not* EXPLAIN ANALYZE) on them, or does that
hang too?

It's not very difficult to write SQL queries that would run for
unreasonable lengths of time, eg by leaving out a critical join
restriction.  I'm wondering if something like that is happening
here.  You've not provided nearly enough info to do more than
speculate, however.

> When a query hangs, even running: SELECT pg_cancel_backend(pid); or SELECT
> pg_terminate_backend(pid); does not unblock it.

Hmm, that's unusual (and a strike against my theory above).
Again, pg_stat_activity output would be helpful here.

> My postgresql.conf:
> listen_addresses = '*'
> max_prepared_transactions = 0
> shared_buffers = 2000MB
> temp_buffers = 8MB
> max_connections = 5010

That max_connections value seems fairly insane.  It doesn't look like
you've provisioned a setup that is anywhere near capable of supporting
so many sessions.  I'd knock it down by at least a factor of 10.

> shared_preload_libraries = 'timescaledb,pg_cron,pg_stat_statements'

I don't suppose you can take timescaledb out of the mix to see
if it's contributing to this.

            regards, tom lane

On Tue, 2025-06-24 at 15:09 -0400, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
> > I’m running PostgreSQL 16.9 in Docker (PostgreSQL 16.9 (Debian
> > 16.9-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc 12.2.0, 64-bit),
> > and intermittently observe that invalid SQL queries hang indefinitely
> > instead of immediately returning an error.
> > Valid queries continue to work normally and return results right away.
>
> You've not provided nearly enough info to do more than
> speculate, however.

Yes.  One speculation that occurs to me is that the control group settings
of your container are such that a process that exceeds the memory quota is
suspended until enough memory becomes free.

Yours,
Laurenz Albe