Which Postgres - RHEL 4 x86_64

[eyalm]

Hi,
I'm planning to upgrade from 10.0.1 to 11.0.1 this weekend.
We are running a RHEL 4 x86_64.
Should I install the postgresql package from up2date? (version 7.4.16-1)?
or download the latest binary version from the postgresql website? (latest version is 8.2.3)

thanks,
Eyal.

[kanderson]

7.4 will work fine, though I believe 8 is recommended.

Kev.

[florian]

In general, for all operating systems with the exception of RHEL3, the Postgres version that comes with the OS can and should be used. For RHEL3, please follow the Release Notes to download a later version as RHEL3 comes with Postgres 7.4, which is not sufficient.

Florian.

[eyalm]

I ended up downloading and installing postgres 8.1.8 from postgres website. Will that be an issue since I'm not using the default postgress that came with my installation?

BTY, im using RHEL version 4

I did the Scalix upgrade, restarted the server and it's running omtidyallu -M right now.
I had no errors so far.

[florian]

We've done our testing on RHEL4 using Postgres 7.4 mostly. However, our use of Postgres is pretty straightforward, so actually any version should work (Even 7.3 creates problems just because of config file changes that the installer doesn't really understand, not real problems).

I think you should be fine. You would need to change this to 7.4 (coming with RedHat) and reinstall the ScalixDB portion of the system to have a fully certified and supported stack (both from RedHat's and our side...)

Florian.

[eyalm]

Thanks florian!

another question. how long should omtidyallu -M last? we have about 600 users w/about 100GB emails.
since it's not showing any progress, I'm not sure if I should check again in a few hours or it just a few more minutes.

Also,
is the a log file I can check for progress/errors on omtidyallu ??

[florian]

In general, please open new forum threads for new questions - that way other people have an easier time finding the information they might be looking for.

Actually, omtidyallu -M shows progress on standard output, e.g.

Code: Select all

[root@sting ~]# omtidyallu -M
Priming mailbox for MIME access for 'sxadmin /sting,scalix/CN=sxadmin'
  InTray: 171 messages
  OutTray: 0 messages
  Folder 'Search Area': 0 items
  Tracking Area: 0 messages
  List Area: 0 messages
  Waste Basket: 0 items

Priming mailbox for MIME access for 'sxqueryadmin /sting,scalix/CN=sxqueryadmin'
  InTray: 0 messages
  OutTray: 0 messages
  Folder 'Search Area': 0 items
  Tracking Area: 0 messages
  List Area: 0 messages
  Waste Basket: 0 items

Priming mailbox for MIME access for 'Nelson Admiral /sting,scalix/CN=Nelson Admiral'
  InTray: 13717 messages
  OutTray: 0 messages
  Folder 'Search Area': 0 items
  Folder 'Calendar': 0 items


However, it prints each line after it has processed the folder. That means if it hasn't printed anything, it most likely is still processing the Inbox of the first user or something is fundamentally wrong.

To see if something is wrong, you can do two things. First, check the output of omshowlog for related errors. Second, do an strace on the omtidyallu process (and other processes forked from it) and see if there is any life.

Now, if this is running for you in the context of a Scalix 10 to Scalix 11 upgrade, it *will* take a while. This is because actually we see two things happening. First, the message store "containers" (i.e. the smallest structures containing the actual messages) have had a format change for Scalix 11, due to the character set support changes. This change will be executed "on access" and as omtidyallu accesses all the messages and containers, it will happen for all of them. Which is good for your users once it's complete, because otherwise it would happen when they open the mailbox and they would then experience these delays. Secondly, omtidyallu -M actually regenerates the cached MIME versions of the messages - this is another intensive operation.

So... we're talking hours for sure and in the case of large, complex message stores (normally #objects is more interesting than size of objects), we might be talking days. Also, have you started the Search/Index-Service (SIS) index generation when you did the install? Or have you executed the sxmkindex command in parallel? This is also a pretty CPU-intensive task and both things executing in parallel will probably take even a bit longer. Also, just to be sure - before you upgraded, have you made sure your message store is consistent, i.e. executed omscan before the upgrade?

Hope this helps,
Florian.

[deyjvu]

The Installation Guide tells you that RHEL3 should have greater than postgresql 7.3 so 7.4 or 8.0 or 8.1.

I upgraded postgresql to 8.0 prior to the Scalix upgrade from 10 to 11.0.2.1 but now when I run the installer it says:

Performing system check...

* Environment check... OK
* Filesystem check... OK
* Network check... OK
* Dependency check... ERROR
* Running services check... OK

System check report:

Environment check passed.

Filesystem check passed.
Network check passed.
Dependency check failed -- Please resolve the following package conflicts and re-run the system checks:
postgresql >= 7.4 is needed by scalix-postgres-11.0.2.23-1
postgresql < 9 is needed by scalix-postgres-11.0.2.23-1
postgresql-server >= 7.4 is needed by scalix-postgres-11.0.2.23-1
postgresql-server < 9 is needed by scalix-postgres-11.0.2.23-1
Suggested resolutions:
/var/spool/up2date/rh-postgresql-7.3.10-2.i386.rpm
/var/spool/up2date/rh-postgresql-server-7.3.10-2.i386.rpm
Running services check passed.

-> Please fix the problems and press Enter to run the system checks again or press CTRL-C to quit [Run Again]:

-> Are you sure you want to quit Scalix Installer? (yes/no) [no] y

Installer interrupted, closing.
Scalix Installer - cleaning up...
Scalix Installer - done.
[root@mail scalix-11.0.2.1-GA]# rpm -qa |grep post
rh-postgresql-libs-7.3.10-2
postgresql-libs-8.0.12-1PGDG
postgresql-server-8.0.12-1PGDG
postgresql-8.0.12-1PGDG

I have tried to uninstall the rh-postgresql-libs-7.3.10-2 but it would not uninstall, says that it has dependencies and lists files that are with in its controls:

rpm -ev rh-postgresql-libs-7.3.10-2
error: Failed dependencies:
libpq.so.3 is needed by (installed) php-pgsql-4.3.2-26.ent
libpq.so.3 is needed by (installed) mod_auth_pgsql-2.0.1-4.ent.1

Is there a way to skip this in the installation and move beyond this?

[ScalixSupport]

Hi!

Did you upgrade the postgres RPM's while upgrading to 8.0. Without clearing the
dependencies, installer would not allow you to continue.

Thanks,
Subir

[deyjvu]

I tried to do an upgrade from 7.3 to 8.0 of postgresql but it wouldn't allow it. Kept complaining about those dependencies in the libs. Same type of error as that seen when I tried to uninstall it.

[ScalixSupport]

Hi!

Can you try installing postgres rpm with --nodeps option, not sure if that helps.

Thanks,
Subir

[florian]

You should actually not be using the nodeps-option. Instead, you should rather be uninstalling php-pgsql, which is just the postgres support module for PHP. Then libs should be able to go away and you should be able to clean dependency mess up. --nodeps should only be used as the last resort, ever, IMHO.

Florian.