Hallo !

Ich habe einen SuSE Server bei server4you auf dem eine mysteriöse
Postgres 7.3.10 Installation läuft.
Unter /usr/bin finde ich die Programme (pg_ctl, postgres, psql, ...),
unter /etc/sysconfig eine Datei postgres, die die Configuration enthält=

und unter /usr/share/pgsql die pg_hba.conf.

Was ich nicht finde, ist ein Verzeichnis wie /usr/local/pgsql wo es das
include-Verzeichnis etc gibt.

Um php für postgres Benutzung zu kompilieren, brauche ich dieses
Verzeichnis jedoch. Also habe ich mir die neueste Postgres Version
heruntergeladen (wenn dann richtig) kompiliert, installiert

../configure
make
make install

und dann php kompiliert.

PHP läuft also mit dem neuesten Modul 8.1.4 während auf dem Server no=
ch
7.3.10 läuft. Einziger biher beobachteter Nebeneffekt ist phpPgAdmin,
welches nicht richtig funktioniert, weil irgendwas fehlt (könnte auch a=
n
was anderem liegen).

Nichts desto trotz würde ich natürlich viel lieber die aktuelle Versi=
on
von Postgres laufen haben.
Ich habe also die Dateien von /usr/local/pgsql/bin nach /usr/bin
kopiert, mit dem Effekt, dass das Postgres Startskript
/etc/init./postgresql ohne Rückmeldung terminiert und keine Postgres
gestartet wird. Mist.

Ganz offensichtlich muss ich noch irgendetwas anderes machen.
Bisher gibt es in meiner Postgres keine Daen, die aufbewahrt werden müs=
sen.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Marco Behnke wrote:
> Was ich nicht finde, ist ein Verzeichnis wie /usr/local/pgsql wo es
> das include-Verzeichnis etc gibt.

Da das ganze als RPM installiert ist, wirst du unter /usr/local auch
nichts finden. Die include-Dateien sind dann normal
unter /usr/include[/pgsql??]. Dazu muss aber das Paket
postgresql-devel installiert sein.

> Ich habe also die Dateien von /usr/local/pgsql/bin nach /usr/bin
> kopiert, mit dem Effekt, dass das Postgres Startskript
> /etc/init./postgresql ohne Rückmeldung terminiert und keine Postgres
> gestartet wird. Mist.

Solche Wursteleien sollte man lieber lassen. Unter
ftp://ftp.suse.com/pub/projects/postgresql gibt's RPMs für alle
Lebenslagen.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Peter Eisentraut schrieb:

>>Ich habe also die Dateien von /usr/local/pgsql/bin nach /usr/bin
>>kopiert, mit dem Effekt, dass das Postgres Startskript
>>/etc/init./postgresql ohne Rückmeldung terminiert und keine Postgres
>>gestartet wird. Mist.
>>
>>
>
>Solche Wursteleien sollte man lieber lassen. Unter
>ftp://ftp.suse.com/pub/projects/postgresql gibt's RPMs für alle
>Lebenslagen.
>
>
Bei den rpms habe ich Probleme gehabt, dass ich von Pontius zu Pilatus
gelaufen bin. installiere bitte noch dies und das und dann auch noch
jenes ... deswegen src.

Ich habe es jetzt aber auch geschafft. Das Problem war ganz einfach zu
lösen und hätte sich mit "rtfm" umgehen lassen können. Ich habe gel=
ernt.

Die Datenbankstrukturen von 7.x sind inkompatibel mit 8.x, deswegen ging
das nicht.

Also:
1) pg_dumpall
2) initdb
3) psql den Dump wieder einspielen
4) die Programme nach /usr/bin kopieren
5) Parameter --lsb bei pg_ctl unter /etc/init.d/postgresql entfernen

Jetzt läuft der neue 8er Server wunderbar. Die Fehler im phppgadmin sin=
d
damit auch entfernt.


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

Marco Behnke wrote:
> Bei den rpms habe ich Probleme gehabt, dass ich von Pontius zu
> Pilatus gelaufen bin. installiere bitte noch dies und das und dann
> auch noch jenes ... deswegen src.

Also wenn eine RPM-Installation noch $X braucht, dann braucht eine
Source-Installation das eigentlich auch. Aber egal ...

Wem derartige Umstände zuwider sind, dem empfehle ich APT.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

Hallo ! Schon gleich meine zweite Frage.

Nachdem ich die Postgres erfolgreich zum Laufen bekomme habe, habe ich
für meine PHP Anwendung ein DB Layer geschrieben und die Daten von MySQ=
L
in die neue DB geschoben. Soweit, so gut :)

Bleibt nur noch das Problem: Sequence

Die Tabellen sind voller Daten, aber die Sequencen stehen bei 1, weil
ich ja schon IDs hatte.

Da es keinen wirklich logischen Zusammenhang zwischen Sequence und Table
gibt, muss ich die Sequencen wohl händisch nachpflegen mit letzter ID
aus table selektieren und value in Sequence setzen, oder?

Oder gibt es dafür doch einen Automatismus?

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

am 24.07.2006, um 13:54:01 +0200 mailte Marco Behnke folgendes:
> Hallo ! Schon gleich meine zweite Frage.

Macht nix...


> Bleibt nur noch das Problem: Sequence
>
> Die Tabellen sind voller Daten, aber die Sequencen stehen bei 1, weil
> ich ja schon IDs hatte.
>
> Da es keinen wirklich logischen Zusammenhang zwischen Sequence und Tabl=
e
> gibt, muss ich die Sequencen wohl händisch nachpflegen mit letzter ID
> aus table selektieren und value in Sequence setzen, oder?
>
> Oder gibt es dafür doch einen Automatismus?

Ja, durchaus. Der 'normale' Weg ist, als Datentyp 'serial' zu verwenden
bzw. die Sequence händisch anzulegen und als Default mit nextval() zu
arbeiten.

Wenn ich Dich bzw. Dein Problem richtig parse, hast Du bereits Daten,
die es zu importieren gilt. Da macht es latürnich wenig Sinn, die
Sequencen für bestehende Daten neu zu vergeben, hier ist es besser, die
Daten erst einmal komplett zu importieren (soweit das geht...) und dann
mit ALTER SEQUENCE ... RESTART WITH ... auf den nächsten zu vergebenden
Wert zu ändern (select max(...)+1 from ...)


Andreas, in der Hoffnung, Dein Problem richtig verstanden zu haben...
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

A. Kretschmer wrote:
> Ja, durchaus. Der 'normale' Weg ist, als Datentyp 'serial' zu verwenden
> bzw. die Sequence händisch anzulegen und als Default mit nextval() zu
> arbeiten.

Den Weg bin ich gegangen, als ich die neuen Tabellen erzeugt habe.

> Wenn ich Dich bzw. Dein Problem richtig parse, hast Du bereits Daten,
> die es zu importieren gilt. Da macht es latürnich wenig Sinn, die

Genau!

> Sequencen für bestehende Daten neu zu vergeben, hier ist es besser, d=
ie
> Daten erst einmal komplett zu importieren (soweit das geht...) und dann
> mit ALTER SEQUENCE ... RESTART WITH ... auf den nächsten zu vergebend=
en
> Wert zu ändern (select max(...)+1 from ...)

Ich habe es befürchtet :( ok, ist ja nur einmal :)

> Andreas, in der Hoffnung, Dein Problem richtig verstanden zu haben...

Absolut erfasst !
Danke.

--
Portrix.net
z. Hd. Marco Behnke
Stresemannstr. 375
22761 Hamburg

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq