Forum OpenACS Development: openacs 5.5.1 with postgres 9.3

Collapse
Posted by Agustín Francesa on
Dear Community,

We are working on the migration from posgresql 8.4 to postgresql 9.3, with .LRN 2.5 and openacs 5.5.1.
We asked the compatibility matrix, community forums and we notice that this migration is not viable.

In spite of this information, we have continued working on it and we believe we made it.
Now, we are working on testing and all is working ok, but we have fear about this migration because we do not have the same experience like you, and we fear that this migration fails.

So, we would like to know, based on your experience, what are the problems that you find in this migration, to know if we solved them or what we have to test and to solve.

All the best,

Collapse
Posted by Antonio Pisano on
I can't speak for .LRN, but regarding upgrade from postgres 8.x to 9.x with OpenAcs I was answered some time ago here:

http://www.openacs.org/forums/message-view?message_id=4124674

...skip my first messages, responses should give you some tip.

Collapse
Posted by Michael Aram on
Dear Agustín,

some weeks ago, I have upgraded an outdated OpenACS instance to the latest and greatest versions; these are my notes. The starting point was an OpenACS instance with mixed version numbers, but most core packages were actually very close to 5.4.3. It was running under Ubuntu 10.04 and Postgres 8.2, using Tcl 8.5.11 and NaviServer 4.99.4.

Based on the information in the wiki, the plan was to upgrade to OpenACS 5.5.1, then switch to PG8.4, then proceed to OpenACS 5.8 and finally to Postgres 9.3.

OpenACS ~5.4.* to 5.5

I did a careful inspection of differences between the actual code, and upstream code. In order to stay on top of things, I upgraded the packages one by one, even the core packages, and all non-proprietary packages (e.g. assessment, categories, …). Eventually everything worked very well.

Postgres 8.2 to 8.4

Dumping and restoring the database between PG8.2 and PG8.4 did work, too. However, one cannot use the flags „stop on error“ or „single transaction“, because of tsearch2, which will throw errors, as documented here.

OpenACS 5.5 to 5.8

Trying to upgrade from OpenACS 5.5 to 5.8 gave me some smaller trouble:

  • First, I stumbled across a bug, which is fixed now - just make sure you have the newest version of the file /packages/acs-kernel/sql/postgresql/upgrade/upgrade-5.7.0d3-5.7.0d4.sql.
  • Starting the server with the 5.5 code, then replacing the core packages with the new 5.8 code does not work, in particular because the new acs-admin package installer web files (sourced on each request) will already require the new "package embedding“ to be there. Hence, one should start up the server with the new 5.8 code. This may lead to (ignorable) errors, as XOTcl-Core is not prioritized „hardcoded" in the load order any more - the new APM recognizes package dependencies, but not at this point in time (new code, but not yet upgraded)
  • Developer support must be upgraded at the same time, as the new core seems to need a new developer support version as well. (invalid command name ::ds_profiling_enabled_p)
  • If you want to stick to NaviServer 4.99.4d, you will encounter errors when upgrading to 5.8 as this code expects the command ns_driversection to be provided by NaviServer already, which is not the case in this version. Hence, strictly speaking, OpenACS 5.8 requires NaviServer 4.99.5 (although this command is defined on the Tcl level and might be added ex post easily.) I have updated the compatibility matrix. Hence, you have to hack /packages/acs-tcl/tcl/security-procs.tcl accordingly. Probably, there, we should not check for „NaviServer“, but for the availability of the proc.
  • If you encounter 'can't read "::acs::rootdir": no such variable‘, be sure to update the files in /tcl as well.
  • There are queries in packages/acs-content-repository/sql/postgresql/upgrade/upgrade-5.8.0d2-5.8.0d3.sql (3 times "delete from cr_item_publish_audit") which run incredibly long on bigger systems and are not necessary „per se“, but should only ensure that the foreign keys can be created later. On larger systems like ours, where these queries can take many many hours, its better to deactivate them and see, if the FKs can be created without them.

Upgrading to NaviServer 4.99.6 with XOTcl 2.0

  • There were a couple of warnings which are now fixed in CVS.
  • Previously, parameter value checking for „integer“ was Tcl-"string is"-based and was not „strict“, i.e. the empty string was allowed. Now the default behavior is „strict“, i.e. to allow the empty string as well, one has to add the multiplicity 0..1, e.g. {-item_id:integer,0..1 "“}.
  • Previously, CrAttribute Slots defined as „required“ were not required upon object instantiation; this is now the case.

Postgres 8.4 to 9.3

Unfortunately, I have no notes with respect to this upgrade. But AFAIR, there were no issues with this...

I hope, some of this helps for doing your upgrade... All the best...
Collapse
Posted by Agustín Francesa on
Dear community, Michael and Antonio.

Thanks for your comments, they are very usefull.

We found another issue, it was the bytea_output variable, to migrate a database from postgres 8.4 to postgres 9.3 is necesary to set the bytea_output variable to "scape". The lob_data table does not work with bytea_output hex (default value in this variable). http://www.postgresql.org/docs/9.3/static/runtime-config-client.html#GUC-BYTEA-OUTPUT

So, now we are working with openACS 5.5, .LRN 2.5 and postgresql 9.3

Thanks again.

All the best,

Collapse
Posted by Gustaf Neumann on
Agustin,

interestingly, we did not see these problems on our installations. if possible, write a short paragraph about the symptom ant the cure to https://openacs.org/xowiki/Postgres_9

many thanks
-g