Add support PostgreSQL 9.6 #108
Comments
|
I confess I've been on other projects lately and have not yet built against 9.6. If you could report here any compilation or runtime errors or areas of incompatibility that you have noticed, that might be helpful as I get back into it. Thanks, |
|
Build result contains this type of warnings: [ERROR] /usr/local/src/pljava/pljava-so/src/main/c/type/Array.c: In function ‘createArrayType’: Petr |
|
Hi, Many warnings of the type Did your build ultimately complete? -Chap |
|
Hi, now compile results in following errors: [ERROR] /usr/local/src/pljava/pljava-so/src/main/c/type/Portal.c: In function ‘Java_org_postgresql_pljava_internal_Portal__1isPosOverflow’: |
|
Hi, I prepared a patch, but I'm not sure if is OK. Especially due removing of function "heap_formtuple": Petr |
|
Thank you for the patch! It looks as if it may resolve the compilation errors, but I will need to look more deeply to be sure of correctness. Also, ultimately, it needs version conditionals so compatibility with older versions doesn't break. We have been using GitHub pull requests in this project to share patches (I understand the PostgreSQL core team doesn't, but here it's the norm). An ideal pull request for this would be a branch for 9.6 compatibility, containing at least: one commit accommodating the loss of If you'd like to work on that, please do! If it seems like a burden, this does seem like something I could get to myself, though it be into next week before I get there. Looking through the 9.6 release notes, the one other thing that looks like attention is needed will be the addition of -Chap |
|
Hello Chap, |
|
I have seen this today after installing on 9.6 with the above patch, what is unusual, I do not think pljava was called explicitly: _ [55502.155269] postgres[28839]: segfault at 148 ip 00007f3b9af4ce9b sp 00007ffcf6462a90 error 4 [55502.155287] postgres[28840]: segfault at 148 ip 00007f3b9af4ce9b sp 00007ffcf6462a90 error 4 [55502.155290] in libpljava-so-1.6.0-SNAPSHOT.so[7f3b9af31000+3a000] _ and of course the whole cluster went down.. |
|
No, I don't recommend the patch as-is. I had optimistically thought I would get to it this week. I'd like to push something this weekend for testing. -Chap |
|
ok, thanks! |
|
just in case this helps, coredump, it happens from time to time for 2,3 processes at the same time so it looks like there is a race during the initialization of parallel workers (even the max gather workers is set to 0). |
|
Thank you for that. It appears to be an issue in addition to the ones I've already identified (right now, I'm still working on the 32-bit things that PG 9.6 widened to 64), so it's good to know about. In general, at the moment, I'd recommend playing with the That's probably not responsible for the Hmm, there could simply be a limitation at the moment for PL/Java in a background worker. It is getting the database name from the |
|
Chris, In your environment, what is causing PL/Java to be loaded in a background worker process? Is there a background worker process being created explicitly and then using PL/Java, or is there a PL/Java function that has been marked parallel-safe and used in a parallel query? |
|
I have pushed a branch -Chap |
|
Thanks Chap! I will try 1_5 branch. |
|
Chris, Have you had a chance to try the I believe what I pushed earlier ought to have solved the compilation issues, but you have probably still seen the issue in your parallel query. I see what is going on now: It turns out I'd like to think I can make that not happen. :) When I do, I'll push a fix for that onto the -Chap |
|
Chris, Please try the most current HEAD of -Chap |
|
Excellent news! I will give the 9.6 a try and will let you know! - I meant the branch you jus announced. Thanks again |
|
Thanks for checking! I trust you mean the But then, it is Halloween.... |
|
Yes, yes, no spooky actions at a distance! |
|
Ghosts strike back unfortunately: under heavy load (100s connections doing heavy work) postgres segfaulted few times, (once ding autovacuum, which should not be related to the one below?). this particular process was using copy + pljava function doing simple array deserialization. |
|
Well, that's less than cheerful. Do you find any lines in the PostgreSQL log resembling: and, if so, what's in the If none of the above got written into the PostgreSQL log file, is there a |
|
no, nothing in the log, nowhere on the filesystem to be found.. |
|
Hmm. Something curious happens in your frame Is there anything in your environment that could be sending I can see one place in the code where the process could possibly send So maybe you could rebuild after commenting out this line, and maybe the default handler would give a more informative dump in case a |
|
You might be right about oom. I have seen oom in the dmesg and it was probably linked with over-configuration of hugepages. We are testing it now. Sorry if it was a false alarm. |
|
I would like nothing more than to believe that, but I've glanced at the oom-killer source and it clearly sends Still, it seems most likely something from outside PL/Java. |
|
I managed to get another segmentation fault with jvm involved, this time using pmpp extension that parallelizes the work based on queries that use pljava: so most likely inducing some races... https://github.com/moat/pmpp/blob/master/src/distribute.c#L638 |
|
It would be very interesting to know just where that signal was raised. Do you have a way to find out which line in I suspect the JVM establishes a Did you see anything that specifically identified the signal as -Chap |
|
Hi, This is what I'm getting on my Fedora 25 box, with GCC 6.3:
|
|
@devrimgunduz, are you able to retry that with a couple extra Maven options?
If you don't have the |
|
Thanks for the reply. Here is the output: Regards, Devrim |
|
@devrimgunduz, have you tried building from the -Chap |
|
Hi @jcflack , no, because this is an RPM build, and it depends on released versions (tarballs) Will you release 1.5.1 that also includes this fix? Actually this is holding 9.5 -> 9.6 upgrades for PL/Java users. Regards, Devrim |
|
@jcflack I created a fake 1.5.1 tarball using that branch, and it compiles fine. I'm still getting these, though, but they don't block the build. So, may I please insist on 1.5.1? :-)
Regards, Devrim |
|
Yes. :) I just need to make sure the right issues are addressed in it, and schedule one (I hope) beta period of a reasonable length, announced over the usual channels. Speaking of rpms, a while back you were having problems because some part of the rpmbuild process was rebuilding the generated jar and creating intermediate directories in it. Did you ever find a way to turn that behavior off? -Chap |
|
@jcflack Well, this is a blocker for the upgrades, so the sooner, the better... Yeah, I fixed the RPM issue for 9.5: https://git.postgresql.org/gitweb/?p=pgrpms.git;a=commit;h=93ab117fa7400b0609db66385718f479eea3ce5a (and a few more followup commits, too). Actually this is why I'm pushing more for 9.6 now ;) Regards, Devrim |
|
@devrimgunduz Hm, so you ended up not running the installable jar at all, but just duplicating the code to put the files in place directly? That seems more brittle to me, more code in the spec file that you would need to keep in sync with the javascript in the jar. Does that mean you never had success with either This is not completely off-topic, because I did want to know whether I needed to put some adjustment into the javascript for 1.5.1 to accommodate that, if you were not able to get either spec file adjustment to work. -Chap |
|
@devrimgunduz have I driven you away by asking about that jar repacking issue? Didn't mean to. I'm just eager for a way to resolve it that doesn't force you to duplicate code. -Chap |
|
I've successfully built pljava on Debian with Postgresql 9.6 and will now test.
|
|
Is Postgres 9.6 supported in Pl/Java REL1_5_STABLE on windows 7 building and installation? I am getting the below Error: |
|
@SDILIPS sorry for my delay. To the best of my knowledge, there is no issue building 1.5.1-BETA1 (or REL1_5_STABLE, which at this moment is nearly equivalent, though I would recommend 1.5.1-BETA1 just for clarity) on Windows. There are, however, two ways of building for Windows (MS Visual Studio or MinGW-w64), and for each way there is a special topics page in the build instructions (msvc or MinGW), so I hope you will read the one of those that applies to your situation, if you haven't already. Also, near the bottom of that build page, there is a section on "Troubleshooting the build", covering many issues that first-time builders run into. If you still have building difficulties after reviewing those, please post again here, and please describe your environment in more detail, and whether you are building with MSVC or with MinGW-w64. Also, please use Thanks! |
|
@jcflack - Thank you for your reply. I am still facing the same error. Below is my detailed description of environment. Also please find attached the output of "mvn clean install -X -Dnar.cores=1" in the output file named "ErrorLog.txt" OS - Windows 7 - 64 bit |
|
Closing with release of 1.5.1. I see there was an unanswered comment on this issue about a failed link when building with MSVC. But I have recent reports of successful 1.5.1 builds with MSVC, so I have to hope that was a fluke that got resolved. |
Please add support for PostgreSQL 9.6. Thanks!
The text was updated successfully, but these errors were encountered: