Re: [Pljava-dev] Draft release notes in preparation for 1.5.1-BETA1

Good Morning Chap, much appreciate your help

On 20/06/2017 17:41, Chapman Flack wrote:
> On 06/20/2017 10:14 AM, Achilleas Mantzios wrote:
>> We got hit by a timestamptz issue which was such a
>> PITA to reproduce outside the function (java standalone was OK, psql was
>> OK, pljava from psql was OK, combination of jboss/pgsql/function gave
>> wrong offset for the EET time zone) that I am terrified on the idea of
>> any change.
> Can you recollect any more details of that? That could be interesting
> to look into. How was it resolved?
>
> I don't believe there's any change in timestamptz implementation
> between current REL1_5_STABLE and master.
>
> If you're able to code up a quick test for the problem you were
> having, it's eminently possible to begin a read-write transaction,
> load a different PL/Java version, and run your test. If you don't
> like what you see, roll back the transaction. :)
Looking at the git log, the issue was there before the upgrade, in the 20120525 snapshot. So we solved that before moving to to 1.6. The bug had to do with timestamp calendar arithmetic, and was
affecting dates around the winter/summer daylight savings changes. We fixed this by making Calendars stick to GMT (timestamptz->Calendar("GMT") was tested to work) and also by adding sanity tests in
the code for boundaries violations. The program has to deal with ILO/IMO work/rest hours, so precise arithmetic up to the minute is needed.

>
>> It was some work to get rid of the old installation/schema of
>> the previous pljava-snapshot.20120525 . Had to run
>> src/pljava-snapshot.20120525.0/src/sql/uninstall.sql and also scrap all
>> settings inside postgresql.conf .
> When was this, just last January? It should have been easier ...
yes, January 2017.
> 1.5.0 introduced (and 1.6... also has) automated schema migration.
> It would have made sense to take unnecessary settings out of
> postgresql.conf, either keeping the necessary ones there, or
> moving them to ALTER DATABASE ... SET ..., but there should have
> been no need to uninstall a version from 20120525. The auto
> migration understands old schemas back to 1.3.0's, from 2006.
>
> Did you try it, and have something go wrong? Do you remember what?
Yes I remember trying schema migration, don't remember why it didn't work. Maybe it didn't have so much to with pljava itself, it was a big migration to the cloud, a lot of stress, a lot of test
environments (which unfortunately *never* match the final production environment) and I just wanted to be on the safe side.
> -Chap
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev(at)lists(dot)pgfoundry(dot)org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

_______________________________________________
Pljava-dev mailing list
Pljava-dev(at)lists(dot)pgfoundry(dot)org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev