Segfault in 1.6.1 in complex query #1841
Comments
|
FWIW, dropping |
|
Hey @akamensky, I was not able to reproduce so far using self-generated data. Could you please provide minimal dataset (or query to generate it) which can be used for easier testing, thanks |
|
@pmwkaa Don't think that would be allowed by company policy. You should be able to generate data based on types in table definition I provided. Also possibly the conditions I added in the top post could help (i.e. no crash on 0 rows result). |
|
@akamensky understood, no worries just had an impression that you used generated data for this test case. I was able to generate some data to match the SELECT query, but did not experience any crash so far, likely I am missing something: INSERT INTO segfaulttable ("createTsMillis", col19, col10, col32, col25, col6)
SELECT time, '123', random(), random(), random(), random() FROM
generate_series('2020-04-22 01:30:00'::timestamptz,
'2020-04-22 04:00:00'::timestamptz,
'1 millisecond') as time;Could you please show the backtrace of the core dump, in case if there are some meaningful information as well? |
|
That should be doable. We are on public holiday at the moment until Monday. I’ll be able to generate core dump on Monday earliest. Will add that then. |
|
@pmwkaa I think i forgot to mention one important setup detail here -- the crash happens on read-only replica host (using postgresql native streaming replication). That may be a factor as well. Have not tried this on primary server (and won't be able to try it due to stability requirements). |
|
@akamensky interesting, thanks for the details |
|
I've tried to create a master-replica setup and reproduce the issue on the replica host. Unfortunately everything seems to be working so far, so any new information would be useful. |
|
Any luck yet? |
|
|
Unfortunately ALL binaries provided by you are stripped of debugging symbols and no separate debugging symbol files are provided. I do not have the capability to compile and debug your code manually. |
|
Full output from GDB session: |
|
@akamensky Thanks for the debug info. Apparently crash happened in the optimization part. Right now I would suggest try to disable it by running:
Otherwise, maybe there is a chance to test it against the latest version which is 1.7.1? |
|
@pmwkaa since our current postgres is 10.9 and support for 10.x is dropped starting 1.7 we could not upgrade to 1.7 (though some desired features are in that release). We are looking to upgrade to latest postgres 12 on those hosts in next few weeks (but will likely be some time until then). Meantime does disabling this option have any effect on performance and/or returned result set? Since this is only happening in our production environment (could not reproduce in test environment), we would like to avoid any impact there. |
|
We are in the middle of upgrading to 1.7.1. Meantime other suggestions did not change the outcome (still segfault). I am not sure whether the issue will be reproducible in 1.7.1, because binary upgrade is not possible due to #1973 |
|
Hi @akamensky Are you able to reproduce it in 1.7.1? |
|
@mfreed Query causing the problem: Table structure: Extra info: Same query without And here is total row count for that table: |
svenklemm
added a commit
to svenklemm/timescaledb
that referenced
this issue
Aug 25, 2020
When postgres prunes children before we create the ChunkAppend path there might be a mismatch between the children of the path and the ordered list of children in a space partitioned hypertable. Fixes timescale#1841
svenklemm
added a commit
to svenklemm/timescaledb
that referenced
this issue
Aug 25, 2020
When postgres prunes children before we create the ChunkAppend path there might be a mismatch between the children of the path and the ordered list of children in a space partitioned hypertable. Fixes timescale#1841
svenklemm
added a commit
that referenced
this issue
Aug 25, 2020
When postgres prunes children before we create the ChunkAppend path there might be a mismatch between the children of the path and the ordered list of children in a space partitioned hypertable. Fixes #1841
svenklemm
added a commit
that referenced
this issue
Aug 25, 2020
When postgres prunes children before we create the ChunkAppend path there might be a mismatch between the children of the path and the ordered list of children in a space partitioned hypertable. Fixes #1841
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Relevant system information:
Centos 7.510.91.6.1yumDescribe the bug
Segfault when running rather complex query:
WHEREclause is used AND when return set is not empty (that is query result would be not 0 rows)"col19" in ('123')or"col19" = '123'(only happens on col19)Table definition:
The query:
The text was updated successfully, but these errors were encountered: