postgresql JDBC driver versions / postgresql versions

[pameyer]

The installer (and presumably default installations) is using the postgresql-9.1 jdbc driver for all postgresql versions >= 9.1. Presumably minor-version compatibility has been reasonably good, or there would've been reports of problems.

---

Ideas:

1. check if existing integration tests break if this isn't comparable with future versions?
2. update later postgresql 9.* series with new JDBC driver jar files?

---

Update added by @pdurbin 2018-07-08

connects to #4709

[pdurbin]

Relates to pull request #3787 for #3786.

[pdurbin]

@pameyer yeah, no problems reported. How about we close this issue until we hear of problems?

[pameyer]

closing because I believe we fixed this in the timer-related work; can be reopened if necessary

[donsizemore]

so, @pameyer a note from @pdurbin sent me down a small rabbit hole. the release notes for 4.8.4 say

For example, if you are running the version 9.3 of PostgresQL, make sure you have the driver postgresql-9.3-1104.jdbc4.jar in your /glassfish/lib directory. The correct version of the driver for your version of PostgreSQL can be found at https://jdbc.postgresql.org/download.html

but the page linked above says

Unless you have unusual requirements (running old applications or JVMs), [the current driver, version 42.1.4] is the driver you should be using. It supports PostgreSQL 8.2 or newer and requires Java 6 or newer.

Just verifying that we do want to continue using Postgres' archived drivers for specific versions (per the Dataverse 4.8.4 release instructions) or should we test with JDBC 42? (which I volunteer to do here at Odum in some basic/initial capacity)

I can open a separate issue about modifying the installer (or bundled dvinstall.zip) to include whichever JDBC drivers are most appropro.

[pdurbin]

I'm re-opening this issue because it sounds like there are open questions and that at the very least, documentation can be improved.

[donsizemore]

update: i've swapped out the existing JDBC driver (some 9.3, most 9.1) with 42.1.4 and the following configurations came back up without complaint:

• RHEL 7, Dataverse 4.8.4
• CentOS 7, Dataverse 4.8 which I in turn step-upgraded to 4.8.4
• CentOS 6, Dataverse 4.7 (running a modified warfile for Data Explorer testing)
• CentOS 7, Dataverse 4.5 (running the Scholars Portal warfile)

I don't see anything interesting in the logs post-update but will check on their EJB timers in a day or two, and have asked our archivists to give them a whirl as Odum contemplates a production upgrade from 4.7.1.

[donsizemore]

So, things were going swimmingly with JDBC 42.1.4 until Jan 11th. until our 4.8.4 test installation harvesting client stalled out, last run: INPROGRESS. I have the oaiSetsUpdate log which looks like it's terminated normally. server.log from that morning doesn't log anything pertinent, at least not by default.

Please let me know if there's anything in particular I can be looking at on this end or if it's simpler for me to drop back to your recommended driver (9.3 to match the Postgres service) and see how things look in another month.

[pdurbin]

@donsizemore sorry, I think I'm missing the connection between the harvesting client and the postgres driver. You suspect the driver is making the client stall?

[donsizemore]

@pdurbin per @landreev and/or @kcondon:

Potential issue with the PostgreSQL JDBC driver version incompatibility causing the Dataverse timer to malfunction. Dataverse uses the EJB timer perform scheduled tasks: harvesting from remote servers and keeping the local OAI sets and metadata exports updated. We've discovered that this timer may stop working if the version of the JDBC driver used by Glassfish is no longer in sync with the version of the PostgreSQL database.

Granted, I'm not seeing the java.io.StreamCorruptedException error and indeed I see 6 entries in EJB__TIMER__TBL, so maybe I'm conflating issues.