Forum OpenACS Q&A: Postgres

Collapse
Posted by Richard Hamilton on
Hi,

I need to upgrade from Postgres 7.2.1 so that I can try OpenACS 5.0. Does anyone know whether Postgres 7.3.6 is safe to use or should I stick with upgrading to 7.3.4.

Thanks
Richard

Collapse
2: Re: Postgres (response to 1)
Posted by Don Baccus on
Why not go to PG 7.4???
Collapse
3: Re: Postgres (response to 2)
Posted by Claudio Pasolini on
I installed OACS 5 with Postgres 7.4 and things work well overall, but I got some errors due to Postgres internal table change: for example schema-browser doesn't work anymore (I don't remember the name of the table wich is missing in 7.4) and so I'm not sure if 7.4 is safe for production use.
Collapse
4: Re: Postgres (response to 3)
Posted by Richard Hamilton on
Thanks guys. Ok so if I understand correctly, an internal table change in Postgres should not affect the OpenACS data model. The schema browser MAY be the only thing affected. However I read some posts that said that pg_dump has been changed again just to make our lives interesting!

My problem is some heavily customised code mixed in with OpenACS 4.6.1. I want to upgrade to OpenACS 5.0 but am dreading doing it because of my changes and customisations. I had hoped to try installing two instances of postgres as a temporary measure but the environment variables that postgres requires will make that impossible (i.e. cannot point LD_LIBRARY_PATH to two places at once can I!?).

Maybe the best thing is to go for 7.3.4 on what is planned to be the production machine and try to upgrade to 7.4 on the development box.

If I wanted to avoid messing with any of my custom code in the photo album and ecommerce modules, what would be the minimum partial upgrade necessary to move a site from 4.6.1 to 4.6.3 so that it will run with Postgres 7.4?

Many Thanks
Richard

Collapse
6: Re: Postgres (response to 1)
Posted by Don Baccus on
Well, the schema browser's the only bit of OpenACS that has knowledge of PG internals, and there's a tradition of sorts of the PG group continuously changing internals in ways that break the scheme browser.

While that's a pity, it's not critical, and it won't affect a running system.

I'd suggest installing PG 7.4 and just trying to run your dump  into it.  The one problem you might run into is that PG 7.3 raised the default identifier length to a maximum of 64 rather than 32 characters (for historical reasons they're stored as char(n) not varchars) and in some modules function names were truncated at 32 chars ... which means that selects etc referencing them won't find them.  That's easy to fix by simply running the CREATE FUNCTION command from the datamodel that defines the function.  You might want to run your dump (just scheme, not data) into a virgin PG 7.2 instance to look for such truncations so you can fix them in your own code as well as "our" code when you restore into 7.3 or 7.4 (only functions, index name truncation and the like are harmless).

Other than that I would be surprised if you had any problem.

By leaping forward to 7.4 now you'll minimize any problems you'll have in upgrading to 7.5 when that inevitably becomes available.  Since you have to move forward at least one version at the moment I suggest you at least *test* moving to PG 7.4 before ruling it out.  It won't take long if all goes well.

Collapse
5: Re: Postgres (response to 1)
Posted by Tilmann Singer on
I'm running an oacs-5-0 site on pg 7.4.1 (debian unstable) without any problems but one: the /admin/groups/one admin page is broken, it fails with

ERROR:  variable not found in subplan target lists

but I guess that is fixed on recent pg versions, judging from this changelog entry: http://www.postgresql.com/news/173.html

So if you go to pg 7.4 make sure you install the latest released version.

Collapse
7: Re: Postgres (response to 5)
Posted by Tilmann Singer on
For restoring the truncated identifiers see bin/pg_7.2to7.3_upgrade_helper.pl in your openacs checkout.

Also note that when restoring a dump into a 7.4 database it is not necessary anymore to manually run acs-kernel/sql/postgresql/postgresql.sql before the restore, on the contrary the restore will fail if you do this before. At least that was my experience - could anyone confirm this behaviour? If yes then we should get this in the docs.

Collapse
8: Re: Postgres (response to 7)
Posted by Richard Hamilton on
Don, Tilmann,

Thanks very much for taking the time to reply.

I will do exactly as you suggest. The only bit I am unclear on is where you said:

"You might want to run your dump (just scheme, not data) into a virgin PG 7.2 instance to look for such
truncations so you can fix them in your own code as well as "our" code when you restore into 7.3 or 7.4 (only functions, index name truncation and the like are
harmless)."

Do I need to do this with PG 7.2 before I try running a restore into 7.4?

Regards
Richard

Collapse
9: Re: Postgres (response to 1)
Posted by Don Baccus on
Actually you might just want to use that helper script Tilman pointed out.  Ignore my comment about dumping->restoring in 7.2 ... that was bogus.