From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Does export operation cancel SQLs? |
Date: | 2025-02-19 16:07:43 |
Message-ID: | CAMkU=1xRrZSJR=k_LaVy-jUe4hp_XXfLN-3QDahz3w+JJ82QcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Wed, Feb 19, 2025 at 10:43 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
wrote:
> On Wed, Feb 19, 2025 at 10:00 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
> wrote:
>
>>
>> No, that message is from a cancel request, like when you interrupt your
>> currently running query with Ctrl+C in "psql" or invoke
>> pg_cancel_backend().
>> PostgreSQL doesn't do that by itself.
>>
>
> The Linux oom killer? I don't remember the exact error message that PG
> gives to the user, but ISTR that it's "user request”. Had to search
> through /var/log/messages to see that oomkiller was the culprit.
>
OOM killer kills a process with sig 9. This reboots the entire cluster,
and you would get some variant of "server closed the connection
unexpectedly" or "terminating connection because of crash of another server
process". So not a "user request".
Most likely some client (or client library) has an internal timer and
cancels its own query after a certain amount of time.
I know that JDBC's setQueryTimeout operates this way, it sets a client side
timeout which then kicks in to cancel the query by "user request".
The server load caused by an export could cause the other queries to
run long enough for this logic to kick in, when they otherwise would not.
Cheers,
Jeff
>
From | Date | Subject | |
---|---|---|---|
Next Message | richard | 2025-02-19 18:55:32 | Re: In-place upgrade with streaming replicas |
Previous Message | Tom Lane | 2025-02-19 16:03:41 | Re: Does export operation cancel SQLs? |