From: Tom Lane <tgl@sss.pgh.pa.us>
To: jeremy.spriet@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18966: Invalid SQL queries hang indefinitely until server
 restart
In-reply-to: <18966-8ca097723a0753f5@postgresql.org>
References: <18966-8ca097723a0753f5@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Tue, 24 Jun 2025 14:10:08 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1152252.1750792153.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 24 Jun 2025 15:09:13 -0400
Message-ID: <1152253.1750792153@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1152253.1750792153%40sss.pgh.pa.us>
Precedence: bulk

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