| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Will Storey <will(at)summercat(dot)com> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Unexpected "canceling statement due to user request" error |
| Date: | 2019-09-02 00:58:30 |
| Message-ID: | 14506.1567385910@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Will Storey <will(at)summercat(dot)com> writes:
> On Sun 2019-09-01 19:46:19 -0400, Tom Lane wrote:
>> A separate question is how come the particular query you're complaining
>> about has (seemingly) a fairly wide window where it never does any
>> CHECK_FOR_INTERRUPTS call before terminating. Perhaps there's someplace
>> we need to sprinkle a few more of those.
> Yeah, it is strange. There are many queries in this system with statement
> timeouts and this is the only one where I see this and it happens several
> times a day.
It'd be interesting to see EXPLAIN ANALYZE output from a typical execution
of that query. Even better would be a test case (w/ tables and dummy
data) so somebody else could reproduce it; but maybe looking at EXPLAIN
ANALYZE would be enough to determine where we're missing checks.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James Sewell | 2019-09-02 04:03:04 | Upgrade 96 -> 11 |
| Previous Message | Will Storey | 2019-09-02 00:21:20 | Re: Unexpected "canceling statement due to user request" error |