Re: BUG #18966: Invalid SQL queries hang indefinitely until server restart
От | Tom Lane |
---|---|
Тема | Re: BUG #18966: Invalid SQL queries hang indefinitely until server restart |
Дата | |
Msg-id | 1152253.1750792153@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18966: Invalid SQL queries hang indefinitely until server restart (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18966: Invalid SQL queries hang indefinitely until server restart
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: