I’ve been trying to install Neon locally on Fedora 34. I have a self-compiled and installed version 15.1 of PostgreSQL - I stopped the server for the install.
In my $PATH, I have
/home/pol/Downloads/db/pg/15.1/inst/bin
I also set $LD_LIBRARY_PATH to
/home/pol/Downloads/db/pg/15.1/inst/lib
I cloned the repo and am following the steps for a local install.
I installed all of the dependencies and Rust without a problem.
I tried modifying the Makefile, but after a few attempts, I gave up. Can anyone tell me where the problem is? There’s mention of a patched version of PostgreSQL - I don’t have one - or does the make process patch the one on my $PATH?
Any help with this issue appreciated. Should you require any futher information, please reply here.
Would you mind double-checking that you’ve cloned the submodules with the patched PostgreSQL as well? neon/vendor/postgres-v14 and neon/vendor/postgres-v15 should contain a bunch of code, including the configure file in each.
If these folders are empty, run git submodule update --recursive in the repository to download submodules and try running make again.
Would you mind double-checking that you’ve cloned the submodules with the patched PostgreSQL as well? neon/vendor/postgres-v14 and neon/vendor/postgres-v15 should contain a bunch of code, including the configure file in each.
I read here
https://github.com/neondatabase/neon
that the preferred default is debug, so instead of trying to run a release build, I deleted my repo and recloned. I checked the neon/vendor/postgres-v14/v15 folders and nothing.
If these folders are empty, run git submodule update --recursive in the repository to download submodules and try running make again.
So, I ran the git submodule update --recursive in my repo’s root and it returned to the prompt immediately - no sign of any git downloading activity. I double-checked the folders anyway and nothing in either.
I ran
make -j`nproc`
command again anyway, but obtained the same error!
I’ve tried various permutations of deleting the repo, recloning and running different commands and the two types of build. Again, nothing in the v14/v15 directories and always returning the error.
I’m curious as to why the patched PostgreSQL doesn’t come down with the git clone process - shouldn’t it? I’ve cloned repos before and had no issues - I’m running the default HEAD branch - not exactly sure what’s going on!
I would be grateful for any further input you might have on the matter and thanks again.
I’m curious as to why the patched PostgreSQL doesn’t come down with the git clone process - shouldn’t it?
It’s a git submodule, they’re not cloned by default, only with git clone --recursive.
no sign of any git downloading activity
Ah, sorry, forgot about one other command: try git submodule initin the repository (should say something like “Submodule … registered for path vendor/postgres-v14”, and for v15 as well) followed by git submodule update --recursive --progress.
Something I do note, though, is that this tries to clone the whole PostgreSQL sources twice, which is fairly expensive due to the size of the history of that repository. You might want to limit the cloned data to only a few commits instead of all historical data:
You were bang on about the --depth 10 - the entire download without it was 2.3GB!
Now, I ran the release build, but apparently only v14 was actually built! This is fine for the time being, but there’s a new problem. Maybe because the release build isn’t the default? But that’s another day’s work - I can use the v14 build for the moment!
I set my paths ( PATH and LD_LIBRARY_PATH) appropriately, but the next section is Running neon database and it has
> ./target/debug/neon_local init
Now, there is noneon_local script anywhere in the built repo - I searched from the root. Neither is there an init script - there’s init directories alright, but no script (or other file) that I could find!
Maybe the BUILD=RELEASE make -jnproc process creates an init script with a different name for the release? Or have I misunderstood the build process?
I’m going to build the default debug release and report back - but ultimately I would like to run the release build. But, it’s late, so I’ll kick it off, but will have to report back tomorrow!
Hi again, and thanks for your efforts on my behalf!
See my answer to @Matthias for the details of the process - maybe you could weigh in?
I’m going to build the default debug release and report back - but ultimately I would like to run the release build. But, it’s late, so I’ll kick it off, but will have to report back tomorrow!
If you want the release version, it’s BUILD_TYPE=release, not BUILD=RELEASE (case-sensitive). neon_local is not a script; it’s a binary executable compiled from Rust.
The BUILD_TYPE=release make -j$(nproc) command should create a target directory in the repository’s root (next to test_runner and scripts directories), which contains either debug or release directory with the binaries. Here is how it looks on my machine in a freshly cloned and built repository:
This gave me the clue that I needed to get the system working! I have read that Rust takes quite a while to compile relative to C for example. I eyeballed my earlier attempts at compiling (make...) and the system flew through them, taking even less time than it usually takes me to compile a normal PostgreSQL cluster.
I double checked this page:
https://www.rust-lang.org/tools/install
esp. the parts about Configuring the PATH environment variable… I tried to run
`rustc --version`
and got
command not found
hangs head in shame…
So, I put my Rust install on my PATH and bingo! System took about 15 mins to complile with lots of Compiling rustc... - and the system ran - smooth sailing!
The reason I made this schoolboy error was that I thought that the Rust install process would do all the path setup and whatnot, and I also thought that the pgx system “turned” (transpiled?) Rust into C (there’s a directory - pgxn in neon) - so initially I thought the fact that there was nothing other than C during the compilation wasn’t necessarily indicative that something was wrong! Plus, I’m not used to using the -jnproc option which is why the fact that it flew through the compile didn’t raise a red flag at first.
Anyway, thanks for all your help - really appreciate it. Like what I’m seeing so far though!
Couple of thoughts - might help eejits like me into the future and not clog up your lists with n00b questions
On the GitHub page, emphasise the recursive bit here git clone --recursive https://github.com/neondatabase/neon.git, maybe “git clone –recursive https…” - basically, I just saw the .git, copied and pasted it. I know I should have actually read it, but it might help?
have a check for the Rust toolchain in the make? Again for muppets like me, but it might save some grief?
Check out my latest answer to @yeputons about how I eventually got the system working () - but I did notice one thing which may (or may not) be relevant to what you wrote above.
I was eye-balling the cloning process (which I went through a number of times) and at first it seemed to me also that there was some sort of double download, but I think it might be the fact that it’s downloading two versions of PostgreSQL (14 & 15) and that may be the double download?
and that worked fine. Maybe --depth 1 would work also?
Might be worth putting a note on the GitHub page suggesting that those who aren’t going to be developing/contributing should use one of these options - saves bandwidth both on their end and yours?
) - but I did notice one thing which may (or may not) be relevant to what you wrote above.