From: | Will Storey <will(at)summercat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-03 23:38:19 |
Message-ID: | 20190903233819.voaqdquwsdk3g5nm@dev.null |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun 2019-09-01 20:58:30 -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.
I put output from a query with values that caused the error here:
I sanitised some of the names and values again. Sorry about that.
As far as a test case: I'm not sure how to reproduce it myself. It just
happens periodically (15 times in the past 24 hours). The tables are
somewhat large (60+ GiB per partition). I could try to generate dummy
versions if you like, but they would have to be significantly dummied, so
I'm not sure it would end up being representative.
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2019-09-04 00:03:30 | Re: Upgrade 96 -> 11 |
Previous Message | Julie Nishimura | 2019-09-03 23:29:03 | Re: killing vacuum analyze process |