make on Windows fails #4
Comments
|
Unfortunately we have not yet tested the extension's build process on Windows. We will add a note in the README on platforms we have tested, and will see what level of commitment is needed to get this working on Windows. |
|
There has been some recent progress on getting Timescale to natively compile on windows (from Visual Studio). See, e.g., PR #228 , although this doesn't (yet) address the build process mechanism described above. |
|
Please keep me informed.
…________________________________
From: Mike Freedman <notifications@github.com>
Sent: Tuesday, October 3, 2017 4:14:54 PM
To: timescale/timescaledb
Cc: John Gillerman; Author
Subject: Re: [timescale/timescaledb] make on Windows fails (#4)
There has been some recent progress on getting Timescale to natively compile on windows (from Visual Studio). See, e.g., PR #228<#228> , although this doesn't (yet) address the build process mechanism described above.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#4 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJZDT2VM35SWMuWQOaOBRfaCW586US9jks5soqPOgaJpZM4MkfPo>.
|
|
Wondering where this is at? We need an on-premise version of our cloud platform that contains a time series database. Thinking that your solution could be a viable option and wondering what the expected time frame for having native Windows support might be and whether there is a way for us to help move it along? |
|
Hi @sonofaforester , glad you're interested. We currently have a PR/branch that will make building the extension on Windows possible: If you would like to help test it by checking out the branch and building/playing with it, that would be great! Once that is merged we will also be able to offer Windows builds for download. |
|
@gillerman Please see @RobAtticus note above: Branch/PR should now build on Windows and we've done various testing, but we'd appreciate others' experience building/using it on Windows. Please let us know! |
|
So I was able to build it by running the bootstrap.bat file and then opening the resulting solution in visual studio and building. I installed the plugin into version 9.6 and was able to create a hypertable, so it seems to be working. Thanks! I wasn't able to build using the Visual Studio CMake integration. I've got VS2017 15.4.2. When I open, the CMake stuff seems to run, but when I open the CMake menu and select Build All, I get a bunch of linker errors. I'm not a C++ guy, so I'm not much help here. ------ Build started: Project: CMakeLists, Configuration: Debug ------ C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\utils.c.obj : error LNK2019: unresolved external symbol _errstart referenced in function _create_fmgr C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\indexing.c.obj : error LNK2001: unresolved external symbol _errstart C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\init.c.obj : error LNK2001: unresolved external symbol _errstart .... (There's 635 errors similar to these) |
|
@sonofaforester Hmm, let me ping @erimatnor since he was the one who tried this using Visual Studio integration. I'm glad you got it working (By the way the PR has landed and will be in the 0.8.0 release) |
|
I've successfully built on windows 10 with VS2015. One thing to note (though maybe it will only affect absolute novices to building C projects like me?!) is that the INSTALL phase needs to be called from VS2015 run as administrator if PostgreSQL is installed in /Program Files/ or a similar protected directory, or write permissions need to be adjusted to the same effect. |
|
With the release of 0.8.0, there is now a way to build on Windows! |
|
Closing this out. Let us know if you have any other issues. |
Whenever paths are added to a rel, that path or another path that previously was on the rel can be freed. Previously, the compressed rel's paths could be freed when it was re-planned by the postgres planner after being created and planned by us. The new path the postgres planner added was cheaper and overwrote and pfreed the old path which we created and saved as a child path of the decompress node. Thus we ended up with a dangling reference to a pfreed path. This solution prevents this bug by removing the path we create from the compressed rel. Thus, the chunk rel now "owns" the path. Note that this does not prevent the compressed rel from being replanned and thus some throw-away planner work is still happening. But that's a battle for another day. The backtrace for the core planner overwriting our path is: ``` frame timescale#4: 0x0000000105c4ed0f postgres`pfree(pointer=0x00007fe20d01a628) at mcxt.c:1035 * frame timescale#5: 0x000000010594c998 postgres`add_partial_path(parent_rel=0x00007fe20d01ae10, new_path=0x00007fe20f800298) at pathnode.c:844 frame timescale#6: 0x00000001058ede4b postgres`create_plain_partial_paths(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10) at allpaths.c:753 frame timescale#7: 0x00000001058edb93 postgres`set_plain_rel_pathlist(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10, rte=0x00007fe20d0198c0) at allpaths.c:727 frame timescale#8: 0x00000001058ed78b postgres`set_rel_pathlist(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10, rti=13, rte=0x00007fe20d0198c0) at allpaths.c:452 frame timescale#9: 0x00000001058e8e16 postgres`set_base_rel_pathlists(root=0x00007fe2113fc668) at allpaths.c:310 frame timescale#10: 0x00000001058e8b49 postgres`make_one_rel(root=0x00007fe2113fc668, joinlist=0x00007fe20d0121c8) at allpaths.c:180 frame timescale#11: 0x000000010591ee77 postgres`query_planner(root=0x00007fe2113fc668, tlist=0x00007fe2113fcb58, qp_callback=(postgres`standard_qp_callback at planner.c:3492), qp_extra=0x00007ffeea6ba2b8) at planmain.c:265 frame timescale#12: 0x00000001059229cb postgres`grouping_planner(root=0x00007fe2113fc668, inheritance_update=false, tuple_fraction=0) at planner.c:1942 frame timescale#13: 0x0000000105920546 postgres`subquery_planner(glob=0x00007fe218000328, parse=0x00007fe218000858, parent_root=0x0000000000000000, hasRecursion=false, tuple_fraction=0) at planner.c:966 frame timescale#14: 0x000000010591f1e7 postgres`standard_planner(parse=0x00007fe218000858, cursorOptions=256, boundParams=0x0000000000000000) at planner.c:405 frame timescale#15: 0x000000010642d9b4 timescaledb-1.5.0-dev.so`timescaledb_planner(parse=0x00007fe218000858, cursor_opts=256, bound_params=0x0000000000000000) at planner.c:152 ```
Whenever paths are added to a rel, that path or another path that previously was on the rel can be freed. Previously, the compressed rel's paths could be freed when it was re-planned by the postgres planner after being created and planned by us. The new path the postgres planner added was cheaper and overwrote and pfreed the old path which we created and saved as a child path of the decompress node. Thus we ended up with a dangling reference to a pfreed path. This solution prevents this bug by removing the path we create from the compressed rel. Thus, the chunk rel now "owns" the path. Note that this does not prevent the compressed rel from being replanned and thus some throw-away planner work is still happening. But that's a battle for another day. The backtrace for the core planner overwriting our path is: ``` frame #4: 0x0000000105c4ed0f postgres`pfree(pointer=0x00007fe20d01a628) at mcxt.c:1035 * frame #5: 0x000000010594c998 postgres`add_partial_path(parent_rel=0x00007fe20d01ae10, new_path=0x00007fe20f800298) at pathnode.c:844 frame #6: 0x00000001058ede4b postgres`create_plain_partial_paths(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10) at allpaths.c:753 frame #7: 0x00000001058edb93 postgres`set_plain_rel_pathlist(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10, rte=0x00007fe20d0198c0) at allpaths.c:727 frame #8: 0x00000001058ed78b postgres`set_rel_pathlist(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10, rti=13, rte=0x00007fe20d0198c0) at allpaths.c:452 frame #9: 0x00000001058e8e16 postgres`set_base_rel_pathlists(root=0x00007fe2113fc668) at allpaths.c:310 frame #10: 0x00000001058e8b49 postgres`make_one_rel(root=0x00007fe2113fc668, joinlist=0x00007fe20d0121c8) at allpaths.c:180 frame #11: 0x000000010591ee77 postgres`query_planner(root=0x00007fe2113fc668, tlist=0x00007fe2113fcb58, qp_callback=(postgres`standard_qp_callback at planner.c:3492), qp_extra=0x00007ffeea6ba2b8) at planmain.c:265 frame #12: 0x00000001059229cb postgres`grouping_planner(root=0x00007fe2113fc668, inheritance_update=false, tuple_fraction=0) at planner.c:1942 frame #13: 0x0000000105920546 postgres`subquery_planner(glob=0x00007fe218000328, parse=0x00007fe218000858, parent_root=0x0000000000000000, hasRecursion=false, tuple_fraction=0) at planner.c:966 frame #14: 0x000000010591f1e7 postgres`standard_planner(parse=0x00007fe218000858, cursorOptions=256, boundParams=0x0000000000000000) at planner.c:405 frame #15: 0x000000010642d9b4 timescaledb-1.5.0-dev.so`timescaledb_planner(parse=0x00007fe218000858, cursor_opts=256, bound_params=0x0000000000000000) at planner.c:152 ```
Whenever paths are added to a rel, that path or another path that previously was on the rel can be freed. Previously, the compressed rel's paths could be freed when it was re-planned by the postgres planner after being created and planned by us. The new path the postgres planner added was cheaper and overwrote and pfreed the old path which we created and saved as a child path of the decompress node. Thus we ended up with a dangling reference to a pfreed path. This solution prevents this bug by removing the path we create from the compressed rel. Thus, the chunk rel now "owns" the path. Note that this does not prevent the compressed rel from being replanned and thus some throw-away planner work is still happening. But that's a battle for another day. The backtrace for the core planner overwriting our path is: ``` frame #4: 0x0000000105c4ed0f postgres`pfree(pointer=0x00007fe20d01a628) at mcxt.c:1035 * frame #5: 0x000000010594c998 postgres`add_partial_path(parent_rel=0x00007fe20d01ae10, new_path=0x00007fe20f800298) at pathnode.c:844 frame #6: 0x00000001058ede4b postgres`create_plain_partial_paths(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10) at allpaths.c:753 frame #7: 0x00000001058edb93 postgres`set_plain_rel_pathlist(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10, rte=0x00007fe20d0198c0) at allpaths.c:727 frame #8: 0x00000001058ed78b postgres`set_rel_pathlist(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10, rti=13, rte=0x00007fe20d0198c0) at allpaths.c:452 frame #9: 0x00000001058e8e16 postgres`set_base_rel_pathlists(root=0x00007fe2113fc668) at allpaths.c:310 frame #10: 0x00000001058e8b49 postgres`make_one_rel(root=0x00007fe2113fc668, joinlist=0x00007fe20d0121c8) at allpaths.c:180 frame #11: 0x000000010591ee77 postgres`query_planner(root=0x00007fe2113fc668, tlist=0x00007fe2113fcb58, qp_callback=(postgres`standard_qp_callback at planner.c:3492), qp_extra=0x00007ffeea6ba2b8) at planmain.c:265 frame #12: 0x00000001059229cb postgres`grouping_planner(root=0x00007fe2113fc668, inheritance_update=false, tuple_fraction=0) at planner.c:1942 frame #13: 0x0000000105920546 postgres`subquery_planner(glob=0x00007fe218000328, parse=0x00007fe218000858, parent_root=0x0000000000000000, hasRecursion=false, tuple_fraction=0) at planner.c:966 frame #14: 0x000000010591f1e7 postgres`standard_planner(parse=0x00007fe218000858, cursorOptions=256, boundParams=0x0000000000000000) at planner.c:405 frame #15: 0x000000010642d9b4 timescaledb-1.5.0-dev.so`timescaledb_planner(parse=0x00007fe218000858, cursor_opts=256, bound_params=0x0000000000000000) at planner.c:152 ```
Whenever paths are added to a rel, that path or another path that previously was on the rel can be freed. Previously, the compressed rel's paths could be freed when it was re-planned by the postgres planner after being created and planned by us. The new path the postgres planner added was cheaper and overwrote and pfreed the old path which we created and saved as a child path of the decompress node. Thus we ended up with a dangling reference to a pfreed path. This solution prevents this bug by removing the path we create from the compressed rel. Thus, the chunk rel now "owns" the path. Note that this does not prevent the compressed rel from being replanned and thus some throw-away planner work is still happening. But that's a battle for another day. The backtrace for the core planner overwriting our path is: ``` frame #4: 0x0000000105c4ed0f postgres`pfree(pointer=0x00007fe20d01a628) at mcxt.c:1035 * frame #5: 0x000000010594c998 postgres`add_partial_path(parent_rel=0x00007fe20d01ae10, new_path=0x00007fe20f800298) at pathnode.c:844 frame #6: 0x00000001058ede4b postgres`create_plain_partial_paths(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10) at allpaths.c:753 frame #7: 0x00000001058edb93 postgres`set_plain_rel_pathlist(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10, rte=0x00007fe20d0198c0) at allpaths.c:727 frame #8: 0x00000001058ed78b postgres`set_rel_pathlist(root=0x00007fe2113fc668, rel=0x00007fe20d01ae10, rti=13, rte=0x00007fe20d0198c0) at allpaths.c:452 frame #9: 0x00000001058e8e16 postgres`set_base_rel_pathlists(root=0x00007fe2113fc668) at allpaths.c:310 frame #10: 0x00000001058e8b49 postgres`make_one_rel(root=0x00007fe2113fc668, joinlist=0x00007fe20d0121c8) at allpaths.c:180 frame #11: 0x000000010591ee77 postgres`query_planner(root=0x00007fe2113fc668, tlist=0x00007fe2113fcb58, qp_callback=(postgres`standard_qp_callback at planner.c:3492), qp_extra=0x00007ffeea6ba2b8) at planmain.c:265 frame #12: 0x00000001059229cb postgres`grouping_planner(root=0x00007fe2113fc668, inheritance_update=false, tuple_fraction=0) at planner.c:1942 frame #13: 0x0000000105920546 postgres`subquery_planner(glob=0x00007fe218000328, parse=0x00007fe218000858, parent_root=0x0000000000000000, hasRecursion=false, tuple_fraction=0) at planner.c:966 frame #14: 0x000000010591f1e7 postgres`standard_planner(parse=0x00007fe218000858, cursorOptions=256, boundParams=0x0000000000000000) at planner.c:405 frame #15: 0x000000010642d9b4 timescaledb-1.5.0-dev.so`timescaledb_planner(parse=0x00007fe218000858, cursor_opts=256, bound_params=0x0000000000000000) at planner.c:152 ```
C:\Program Files\PostgreSQL\timescaledb-master>"C:\Program Files (x86)\GnuWin32\bin\make.exe"
process_begin: CreateProcess(NULL, pg_config --pgxs, ...) failed.
'cat' is not recognized as an internal or external command,
operable program or batch file.
'cat' is not recognized as an internal or external command,
operable program or batch file.
process_begin: CreateProcess(NULL, cat sql/load_order.txt, ...) failed.
'cat' is not recognized as an internal or external command,
operable program or batch file.
'cat' is not recognized as an internal or external command,
operable program or batch file.
make: Nothing to be done for `all'.
The text was updated successfully, but these errors were encountered: