Bug 36376 – PostgreSQL migration from 8.4 to 9.1

Bug 36376 - PostgreSQL migration from 8.4 to 9.1


Summary:	PostgreSQL migration from 8.4 to 9.1

Status:	CLOSED FIXED

Product:	Z_SDB
Classification:	Unclassified
Component:	New entries
Version:	unspecified
Hardware:	Other Linux

Importance:	P5 normal
Target Milestone:	UCS 4.0-0-errata
Assigned To:	Philipp Hahn
QA Contact:	Felix Botner

URL:
Keywords:

Depends on:	36371
Blocks:
	Show dependency tree / graph

Reported:	2014-10-31 23:02 CET by Stefan Gohmann
Modified:	2015-09-18 16:04 CEST (History)
CC List:	4 users (show)

See Also:
What kind of report is it?:	---
What type of bug is this?:	---
Who will be affected by this bug?:	---
How will those affected feel about the bug?:	---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Stefan Gohmann

2014-10-31 23:02:18 CET

+++ This bug was initially created as a clone of Bug #36371 +++

Update with postgresql-8.4 works, postgresql-8.4 is not removed and postgresql-9.1 not installed during the update. Database still works. But we may need an acticle how to upgrade from 8.4 to 9.1.

Comment 1 Philipp Hahn

2014-11-24 16:41:50 CET

<http://sdb.univention.de/admin/index.php?action=editentry&id=284&lang=en>

Please note that "pg_upgradecluser" prints the following error message: This happens because the configuration files in /etc/postgresql/9.1/main/ are removed before installing (they are UCR configuration files, which break the installation of version 9.1) and PostgreSQL then picks a too large SHMMAX size. After commiting the files PostgreSQL start fine.
As pg_upgradecluster does all the magic about temporarily starting the old version on a different port and copying over the config files, it's not possible to interrupt in between for commiting the files in the right moment. (the script supports hook scripts, but that's IMHO overkill for a one-time upgrade)

2014-11-24 15:52:37 CET FATAL: konnte Shared-Memory-Segment nicht erzeugen: Das Argument ist ung?ltig
2014-11-24 15:52:37 CET DETAIL: Fehlgeschlagener Systemaufruf war shmget(Key=5432001, Gr?sse=36954112, 03600).
2014-11-24 15:52:37 CET TIPP: Dieser Fehler bedeutet gew?hnlich, dass das von PostgreSQL angeforderte Shared-Memory-Segment den Kernelparameter SHMMAX ?berschreitet. Sie k?nnen entweder die ben?tigte Shared-Memory-Gr?sse reduzieren oder SHMMAX im Kernel gr?sser konfigurieren. Um die ben?tigte Shared-Memory-Gr?sse zu reduzieren (aktuell 36954112 Bytes), reduzieren Sie den Shared-Memory-Verbrauch von PostgreSQL, beispielsweise indem Sie >>shared_buffers<< oder >>max_connections<< reduzieren.
Wenn die angeforderte Gr?sse schon klein ist, ist es m?glich, dass sie kleiner ist als der Kernelparameter SHMMIN. Dann m?ssen Sie die ben?tigte Shared-Memory-Gr?sse erh?hen oder SHMMIN ?ndern.
Die PostgreSQL-Dokumentation enth?lt weitere Informationen ?ber die Konfiguration von Shared Memory.
Error: Could not start target cluster; please check configuration and log files

Comment 2 Felix Botner

2014-12-04 14:38:20 CET

OK