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

I have just pushed a draft of PL/Java 1.5.1 release notes
in anticipation of making a -BETA1 release:

https://github.com/tada/pljava/blob/REL1_5_STABLE/src/site/markdown/releasenotes.md.vm

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

Hello,

we've been running git's head 1.6.0-SNAPSHOT for quite some time (since January) with no issues.

On 19/06/2017 19:44, Chapman Flack wrote:
> I have just pushed a draft of PL/Java 1.5.1 release notes
> in anticipation of making a -BETA1 release:
>
> https://github.com/tada/pljava/blob/REL1_5_STABLE/src/site/markdown/releasenotes.md.vm
>
> -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

On 06/20/17 02:29, Achilleas Mantzios wrote:

> we've been running git's head 1.6.0-SNAPSHOT for quite some time (since
> January) with no issues.

Hi,

That's good to know, but the 1.6.x line of development is very much
work-in-progress at the moment ... it may even be renamed 2.0.0
before it approaches release, and that will not be for some time yet.

I have avoided pushing (knowingly!) any changes that leave it broken,
but it won't be anything I'd recommend relying on until it is ready
to go through a beta and a release.

I assume you are using it with PG 9.5 or earlier? PL/Java 1.5.1 is
currently where the changes have been made to accommodate 9.6 and 10;
those have not (in fact, none of the changes new in 1.5.1 have) been
merged into the 1.6.0-SNAPSHOT line yet. I expect to merge them all in
en masse after 1.5.1 has a final release.

-Chap

Hey Thanx

On 20/06/2017 15:16, Chapman Flack wrote:
> On 06/20/17 02:29, Achilleas Mantzios wrote:
>
>> we've been running git's head 1.6.0-SNAPSHOT for quite some time (since
>> January) with no issues.
> Hi,
>
> That's good to know, but the 1.6.x line of development is very much
> work-in-progress at the moment ... it may even be renamed 2.0.0
> before it approaches release, and that will not be for some time yet.
I thought the general consensus was to git clone the HEAD : https://github.com/tada/pljava.git , at least that's what I gathered from the old pages.
> I have avoided pushing (knowingly!) any changes that leave it broken,
> but it won't be anything I'd recommend relying on until it is ready
> to go through a beta and a release.
>
> I assume you are using it with PG 9.5 or earlier?

Yes 9.3 , we have a long way till we move to 9.6 or 10.

> PL/Java 1.5.1 is
> currently where the changes have been made to accommodate 9.6 and 10;
> those have not (in fact, none of the changes new in 1.5.1 have) been
> merged into the 1.6.0-SNAPSHOT line yet. I expect to merge them all in
> en masse after 1.5.1 has a final release.
>
> -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

On 06/20/17 08:32, Achilleas Mantzios wrote:

> I thought the general consensus was to git clone the HEAD :
> https://github.com/tada/pljava.git , at least that's what I gathered from
> the old pages.

There /was/ a long period before the release of 1.5.0 where that was
the only way to get any of the changes made since the release of 1.4.3
back in 2011.

The current intent is to stick to a more conventional plan with
named tagged releases. For the last couple months, it has been
possible for the impatient to build (most of) the upcoming 1.5.1
by git cloning and checking out REL1_5_STABLE, which is (as the
name suggests) less adventurous than building whatever's on the
head of master, but it is still more adventurous than using a release.

-Chap

On 20/06/2017 15:48, Chapman Flack wrote:
> On 06/20/17 08:32, Achilleas Mantzios wrote:
>
>> I thought the general consensus was to git clone the HEAD :
>> https://github.com/tada/pljava.git , at least that's what I gathered from
>> the old pages.
> There /was/ a long period before the release of 1.5.0 where that was
> the only way to get any of the changes made since the release of 1.4.3
> back in 2011.
>
> The current intent is to stick to a more conventional plan with
> named tagged releases. For the last couple months, it has been
> possible for the impatient to build (most of) the upcoming 1.5.1
> by git cloning and checking out REL1_5_STABLE, which is (as the
> name suggests) less adventurous than building whatever's on the
> head of master, but it is still more adventurous than using a release.
Thanx for the update. So what do you recommend for our case? By the time we move to 10 (might be one year from now), just try to re-install the corresponding latest stable version of pl/java?
>
> -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

On 06/20/2017 09:08 AM, Achilleas Mantzios wrote:
> Thanx for the update. So what do you recommend for our case? By the time
> we move to 10 (might be one year from now), just try to re-install the
> corresponding latest stable version of pl/java?

I would recommend going to PL/Java 1.5.1 once it reaches full
(not beta) release, irrespective of when you plan to upgrade
PostgreSQL. Then you'll be running the latest official release,
and when you do later upgrade PostgreSQL, PL/Java will need no
extra attention. (As a bonus, PL/Java 1.5.1 plays well with
pg_upgrade, so you can binary-upgrade the cluster when the time
comes.)

Moving to 1.5.1 from 1.6.0-SNAPSHOT might look like a 'downgrade',
but should be fairly straightforward to do, as the 1.6.0-SNAPSHOT
line has not made any incompatible schema changes (yet).

Did you install with CREATE EXTENSION, or a plain LOAD?

-Chap

On 20/06/2017 16:35, Chapman Flack wrote:
> On 06/20/2017 09:08 AM, Achilleas Mantzios wrote:
>> Thanx for the update. So what do you recommend for our case? By the time
>> we move to 10 (might be one year from now), just try to re-install the
>> corresponding latest stable version of pl/java?
> I would recommend going to PL/Java 1.5.1 once it reaches full
> (not beta) release, irrespective of when you plan to upgrade
> PostgreSQL. Then you'll be running the latest official release,
> and when you do later upgrade PostgreSQL, PL/Java will need no
> extra attention. (As a bonus, PL/Java 1.5.1 plays well with
> pg_upgrade, so you can binary-upgrade the cluster when the time
> comes.)
Thank you, for the moment it is just a function which happens to run correctly. So no worries I hope. If we run to problems then I'll consider doing this. 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.
> Moving to 1.5.1 from 1.6.0-SNAPSHOT might look like a 'downgrade',
> but should be fairly straightforward to do, as the 1.6.0-SNAPSHOT
> line has not made any incompatible schema changes (yet).
>
> Did you install with CREATE EXTENSION, or a plain LOAD?
With CREATE EXTENSION. But the maven build was done manually from source. 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 .
>
> -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

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. :)

> 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 ...
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?

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

On 06/20/2017 10:14 AM, Achilleas Mantzios wrote:
> We got hit by a timestamptz issue which was such a

By the way, what's your OS?

-Chap

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

On 20/06/2017 18:27, Chapman Flack wrote:
> On 06/20/2017 10:14 AM, Achilleas Mantzios wrote:
>> We got hit by a timestamptz issue which was such a
> By the way, what's your OS?
FreeBSD for personal development and testing. Many Linux'es for testing and production.
>
> -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