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
