References: <5947FF8B.9040803@anastigmatix.net> <7a9451ce-eed8-ddec-4fff-add3cfb351f9@matrix.gatewaynet.com> <5949120C.2080705@anastigmatix.net> <5949198B.3080304@anastigmatix.net> <87160f24-02f5-60cd-27df-aca8d3de1be8@matrix.gatewaynet.com> From: Achilleas Mantzios Message-ID: Date: Tue, 20 Jun 2017 17:14:21 +0300 MIME-Version: 1.0 In-Reply-To: Subject: Re: [Pljava-dev] Draft release notes in preparation for 1.5.1-BETA1 Content-Type: multipart/mixed; boundary="===============6221366745601067148==" This is a multi-part message in MIME format. --===============6221366745601067148== Content-Type: multipart/alternative; boundary="------------2A4E2B388208AA242C9225FE" Content-Language: en-US This is a multi-part message in MIME format. --------------2A4E2B388208AA242C9225FE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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@lists.pgfoundry.org > http://lists.pgfoundry.org/mailman/listinfo/pljava-dev -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt --------------2A4E2B388208AA242C9225FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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@lists.pgfoundry.org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev



-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
--------------2A4E2B388208AA242C9225FE-- --===============6221366745601067148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pljava-dev mailing list Pljava-dev@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev --===============6221366745601067148==--