Le 13/10/2023 à 18:48, Jeff Janes a écrit :
Yes, turning off overcommit doesn't play with graphical environments, in my experience. But a production database probably shouldn't be running on a system like that. On non-prod systems, you can either turn it off temporarily, or you could try to catch the problem before it becomes fatal and get the log with pg_log_backend_memory_contexts.
As I said, this is my dev laptop and no, I would never waste precious RAM this way on a production server ;-)
We can see what the problem is (over 137,000 concurrent tuple sorts), but we can't tell what is ultimately causing it. You will need to dig into, or disclose, the contents of the procedure.
I have no problem disclosing this code and data to the PG dev team (this is client data though so please keep it for yourselves). Where can I send you a link to the dump ?
Best, JC
