Re: Installation über Remote-Desktop

Hallo,

hat sich schon jemand den c't Datenbank-Contest in Ausgabe 20/2005, Seite
156 ff. angeschaut?

Online gibt es ein paar Sachen hier: <http://www.heise.de/ct/dbcontest/>

Vielleicht könnten ja ein paar Leute gemeinsam da etwas basteln ...

Ciao
Alvar

--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

Hallo,

Ich habe gerade versucht PostgreSQL Win32-Version über eine
Remote-Desktop-Verbindung auf einem Server zu installieren. Leider bricht
das Setup mit folgender Meldung ab:
"The PostgreSQL installer must be run on the system console, not in a
terminal services session."

Eine lokale Installation ist nicht möglich. Ich habe keinen physikalischen
Zugang zum RZ.

Ich bin mir ziemlich sicher, dass das mit einer der ersten Versionen noch
funktioniert hat.

Kann das irgendwie umgangen werden, bzw. gibt es einen bestimmten Grund
warum das verhindert wird?

Matthias Zirngibl schrob:

> Kann das irgendwie umgangen werden, bzw. gibt es einen bestimmten Grund
> warum das verhindert wird?

Ja und Ja; Siehe FAQ:
<http://pginstaller.projects.postgresql.org/faq/FAQ_windows.html#3.5>

HTH
Andreas
--

> Ich habe gerade versucht PostgreSQL Win32-Version über eine
> Remote-Desktop-Verbindung auf einem Server zu installieren.
> Leider bricht das Setup mit folgender Meldung ab:
> "The PostgreSQL installer must be run on the system console,
> not in a terminal services session."

Habe mir die Frage gerade selbst beantwortet:
http://pginstaller.projects.postgresql.org/faq/FAQ_windows.html#3.5

Am Mittwoch, 21. September 2005 11:40 schrieb Alvar Freude:
> hat sich schon jemand den c't Datenbank-Contest in Ausgabe 20/2005, Seite
> 156 ff. angeschaut?

Es wäre wohl ganz gut, wenn da eine (oder mehrere) PostgreSQL-basierte
Lösungen eingeschickt würden. Hat schon mal jemand geschaut, was für ein
Aufwand das wird? So wie ich das sehe, gibt's da zur Zeit noch gar keine
PostgreSQL-Unterstützung.

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

Hallo Peter,

-- Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> Es wäre wohl ganz gut, wenn da eine (oder mehrere) PostgreSQL-basierte
> Lösungen eingeschickt würden. Hat schon mal jemand geschaut, was für
> ein Aufwand das wird? So wie ich das sehe, gibt's da zur Zeit noch gar
> keine PostgreSQL-Unterstützung.

ich habe mal reingeschaut und werde wohl was bauen (sofern nichts mehr
dazwischen kommt). PostgreSQL-Unterstützung gibt es bisher nicht.

Im Prinzip ist alles mehr oder weniger Standard-SQL, bis auf die
Volltext-Suche. Wobei das, wenn ich das richtig verstanden habe, auch
keine "echte" Volltextsuche ist, sondern nur nach dem Titel; evtl. ließe
sich das auch mit "normalem" Index auf Textfeld erschlagen (was dann ja
deutlich schneller sein dürfte).

Ich wollte erstmal das bisherige hier zum Vergleich zum Laufen bringen,
hatte noch nicht viel zeit und bisher scheiterte es daran, dass MySQL
sich mit GCC 4.0 (OS X) nicht compilieren ließ und das PHP auch
herumzickt und in den Darwinports nur mit MySQL 3 oder 4 will ;-)

Ich werde etwas mit mod_perl bauen, erstmal die vorhandene
MySQL-Implementierung unterstützen und dann auf PostgreSQL gehen. Mit
DBI lassen sich dann gleich mehrere Datenbanken unterstützen und ich
kann das dann zumindest mit MySQL vergleichen ;-)

Wobei ich mir eigentlich sicher bin, dass es mit PostgreSQL schneller
wird als mit MySQL ...

Ciao
Alvar

--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

Also sprach Alvar Freude (alvar(at)a-blast(dot)org)

> Ich werde etwas mit mod_perl bauen, erstmal die vorhandene
> MySQL-Implementierung unterstützen und dann auf PostgreSQL gehen. Mit
> DBI lassen sich dann gleich mehrere Datenbanken unterstützen und ich
> kann das dann zumindest mit MySQL vergleichen ;-)

Also ich verwende bisher eigentlich nur Perl für meine PG Projekte,
kann da also evtl. auch mithelfen, sofern es zeitlich mit meinem
Studium und den diversen Projekten klappt.

Für Apache sollten wir auf alle Fälle eine persistente Verbindung mit
Apache::DBI nehmen. Soweit ich das verstanden habe ist ja die GUI eher
sekundär, dann sollten wir auf Eyecandy auch verzichten.

--
PGP FPR: CF74 D5F2 4871 3E5C FFFE 0130 11F4 C41E B3FB AE33
--
Der Geist des Kriegers sollte mit Beginn des Neujahrstages bis zum Ende
des Jahres vom Gedanken an seinen Tod beherrscht werden.

Daijouji Shigesuke in "Budo Shoshin Shuu"

Hallo,

-- Stefan 'Kaishakunin' Schumacher <stefan(at)net-tex(dot)de> wrote:

> Also ich verwende bisher eigentlich nur Perl für meine PG Projekte,
> kann da also evtl. auch mithelfen, sofern es zeitlich mit meinem
> Studium und den diversen Projekten klappt.

OK, prima, ich melde mich sobald ich was habe.
Im Augenblick läuft der nächste versuch, PHP mit mysqli-Unterstützung
aus den Darwinports zu bauen ... (*grusel*) ;-)

> Für Apache sollten wir auf alle Fälle eine persistente Verbindung mit
> Apache::DBI nehmen. Soweit ich das verstanden habe ist ja die GUI eher
> sekundär, dann sollten wir auf Eyecandy auch verzichten.

ja, das ist klar. die GUI bleibt 1:1 so wie sie ist, und wenn der
Perl-Code relevante Zeit verbraucht, könnte man ja noch eine
mod_parrot-Version bauen ;-)

Ich denke aber mal, dass >90% der Zeit in der DB verbraten werden, denn
der Code besteht ansonsten fast nur aus SQL-Aufrufen und der Ausgabe. Mit
bind_params usw. gibt es da dann nicht viel zu tun für Perl.

... und vielleicht finden wir ja auch was, wo sich Postgres optimieren
lässt.

Ciao
Alvar

--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

Hallo allerseits,

für den c't Datenbank-Contest bin ich am überlegen, in welchen Sprachen
ich die Funktionen baue ... ;-)

Hat jemand Erfahrungswerte, was die Performance von PL/pgSQL vs. PL/perl
anbelangt?

Wenn ich das richtig verstanden habe, wird PL/perl-Code ja beim erstellen
compiliert und dann im Bytecode nur noch die Unterfunktion aufgerufen.
Wie ist das bei PL/pgSQL und wie ist der Performance-Unterschied?

Es gibt ja wohl auch ein PL/parrot, das habe ich auf die Schnelle aber
nicht gefunden; da würde mich natürlich auch das gleiche interessieren
und vor allem, ob da JIT läuft ... :)

Werde wohl an diesem Wochenende endlich dazu kommen, meine eigene
mod_perl-Version lauffähig zu haben, so dass es dann ans Eingemachte
gehen kann.

Ciao
Alvar

--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

Alvar Freude schrob:

> Hat jemand Erfahrungswerte, was die Performance von PL/pgSQL vs. PL/perl
> anbelangt?

Nur ein paar bescheidene.

> Wenn ich das richtig verstanden habe, wird PL/perl-Code ja beim erstellen
> compiliert und dann im Bytecode nur noch die Unterfunktion aufgerufen.
> Wie ist das bei PL/pgSQL

Geparst wird hier ebenfalls nur beim ersten Funktionsaufruf. PL/pgSQL
bedient sich zum Parsen und Ausführen ausgiebig vom restlichen
PostgreSQL-Code, was es besonders leichtgewichtig macht. Stichwort:
working set.

> und wie ist der Performance-Unterschied?

Depends.

Wenn man SQL einfach nur zur Turing-Vollständigkeit nachrüsten will,
ist PL/pgSQL sicherlich eine gute Wahl, da es mit den PostgreSQL
bekannten Datentypen nativ umgehen kann. Wenn es um nichttriviales
verwursten von Daten über PostgreSQLs eingebauten Funktionsumfang
hinaus geht, wird PL/pgSQL jedoch kaum an PL/Perls Performance
herankommen.

Als unakzeptablen Flaschenhals hab' ich stored procedures allerdings
nur beim Number-Crunching erlebt. Und da war der Ausweg nicht etwa
eine andere PL, sondern:
<http://www.postgresql.org/docs/8.0/static/xfunc-c.html>

> Es gibt ja wohl auch ein PL/parrot, das habe ich auf die Schnelle aber
> nicht gefunden; da würde mich natürlich auch das gleiche interessieren
> und vor allem, ob da JIT läuft ... :)

IMHO genügt es, daß dieser Dell-Benchmark im Alphastadium ist; da muß
man der c't-Redaktion nicht noch eine PL/Parrot-Alpha aufdrücken :-).

Gruß
Andreas
--

Hallo Andreas,

-- Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org> wrote:

> Geparst wird hier ebenfalls nur beim ersten Funktionsaufruf. PL/pgSQL
> bedient sich zum Parsen und Ausführen ausgiebig vom restlichen
> PostgreSQL-Code, was es besonders leichtgewichtig macht. Stichwort:
> working set.

OK, verstehe!

Ich hatte mal bei ein paar relativ einfachen Sachen den Unterschied
zwischen PL/SQL und PL/pgSQL gemessen, und da war pgSQL deutlich
schneller. Das deckt sich dann ja damit.

> Wenn man SQL einfach nur zur Turing-Vollständigkeit nachrüsten will,
> ist PL/pgSQL sicherlich eine gute Wahl, da es mit den PostgreSQL
> bekannten Datentypen nativ umgehen kann. Wenn es um nichttriviales
> verwursten von Daten über PostgreSQLs eingebauten Funktionsumfang
> hinaus geht, wird PL/pgSQL jedoch kaum an PL/Perls Performance
> herankommen.

das klingt einleuchtend ;-)
Klar, wenn man irgendwelche größeren Berechnungs-Orgien und zum
Beispiel Hash- und Stringoperationen durchführt, dann ist das mit
SQL-Sachen nicht mehr so einfach.

BTW: Interessant wäre in dem Zusammenhang, wenn Perl sich globalen,
zwischen allen Prozessen gesharten Speicher holen bzw. nutzen könnte.
Aber das mache ich lieber auf Apache-Seite (beim Startup) ;-)

> Als unakzeptablen Flaschenhals hab' ich stored procedures allerdings
> nur beim Number-Crunching erlebt. Und da war der Ausweg nicht etwa
> eine andere PL, sondern:
> <http://www.postgresql.org/docs/8.0/static/xfunc-c.html>

klar, an sauber geschriebenes C kommt nix heran.

> IMHO genügt es, daß dieser Dell-Benchmark im Alphastadium ist; da muß
> man der c't-Redaktion nicht noch eine PL/Parrot-Alpha aufdrücken :-).

hehe ;-)

Ja, dieses Dell-Zeug ist schon ziemlich grausam. Sowohl das SQL aber vor
allem der PHP/ASP/JSP-Zeug; solch schlechten Code sieht man selten, wobei
man auch hier sieht: bei ASP haben sie sich am meisten Mühe gegeben, wie
beim MS SQL-Server.

Ciao
Alvar

--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

* Alvar Freude <alvar(at)a-blast(dot)org> schrieb:

<snip>

> > Geparst wird hier ebenfalls nur beim ersten Funktionsaufruf. PL/pgSQL
> > bedient sich zum Parsen und Ausführen ausgiebig vom restlichen
> > PostgreSQL-Code, was es besonders leichtgewichtig macht. Stichwort:
> > working set.

Gerüchten zufolge soll es zT. auch möglich sein, daß
(einfache) SQL-Funktionen direkt in den query-tree eingeklebt
und vom planner entsprechend besser behandelt werden können.

<snip>

> BTW: Interessant wäre in dem Zusammenhang, wenn Perl sich globalen,
> zwischen allen Prozessen gesharten Speicher holen bzw. nutzen könnte.
> Aber das mache ich lieber auf Apache-Seite (beim Startup) ;-)

Kannst Du. AFAIK gibt es ein Modul zum Zugriff auf shared memory.
Du könntest einfach Deine Daten serialisieren und dort reinpacken.
Allerdings hast Du damit die gleichen Probleme zu bewältigen,
wie üblicherweise auch beim session-Management (locking, etc).

cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact(at)metux(dot)de
---------------------------------------------------------------------
Realtime Forex/Stock Exchange trading powered by postgreSQL :))
http://www.fxignal.net/
---------------------------------------------------------------------

>> BTW: Interessant wäre in dem Zusammenhang, wenn Perl sich globalen,
>> zwischen allen Prozessen gesharten Speicher holen bzw. nutzen könnte.
>> Aber das mache ich lieber auf Apache-Seite (beim Startup) ;-)

> Kannst Du. AFAIK gibt es ein Modul zum Zugriff auf shared memory.
> Du könntest einfach Deine Daten serialisieren und dort reinpacken.
> Allerdings hast Du damit die gleichen Probleme zu bewältigen,
> wie üblicherweise auch beim session-Management (locking, etc).

"perldoc -f shmctl" existiert zwar, aber ich glaube nicht, daß Alvar
das meinte: auf dieser Ebene weißt Du nicht, wann der Postmaster einen
Backend-Prozeß startet oder beendet.

Derzeit geistert in den englischsprachigen Mailinglisten die Idee
herum, eigene SHM-Bereiche für beliebige Erweiterungen anzubieten,
nicht nur für PL/Perl.

* Harald Fuchs <hf0923x(at)protecting(dot)net> schrieb:

<snip>
> "perldoc -f shmctl" existiert zwar, aber ich glaube nicht, daß Alvar
> das meinte: auf dieser Ebene weißt Du nicht, wann der Postmaster einen
> Backend-Prozeß startet oder beendet.

idR. mit jeder neuen connection.
Wenn Du perl dazu bringen kannst, bestimmte Variablen innerhalb eines
Prozesses persistent zu halten (also zwischen verschiedenen Aufrufen),
dann kannst Du dort einfach ein Flag setzen.

Mit pl/php geht das wunderschön: globale Variablen sind persistent
(weil ja die engine nur einmal pro Prozess gestartet wird) und damit
hast Du einen backend-weiten globalen Speicher. Eignet sich zB.
gut nett fürs caching.

> Derzeit geistert in den englischsprachigen Mailinglisten die Idee
> herum, eigene SHM-Bereiche für beliebige Erweiterungen anzubieten,
> nicht nur für PL/Perl.

Hört sich natürlich gut an.

cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact(at)metux(dot)de
---------------------------------------------------------------------
Realtime Forex/Stock Exchange trading powered by postgreSQL :))
http://www.fxignal.net/
---------------------------------------------------------------------

Hallo,

> Als unakzeptablen Flaschenhals hab' ich stored procedures allerdings
> nur beim Number-Crunching erlebt. Und da war der Ausweg nicht etwa
> eine andere PL, sondern:
> <http://www.postgresql.org/docs/8.0/static/xfunc-c.html>

PL/Python mit dem Numpy-Modul dürfte wohl kaum wesentlich langsamer
sein als selbstgemachtes C, dafür drastisch mächtiger und
benutzerfreundlicher.

MfG

Wolfgang Keller

--
P.S.: My From-address is correct

Hallo,

-- Enrico Weigelt <weigelt(at)metux(dot)de> wrote:

> Gerüchten zufolge soll es zT. auch möglich sein, daß
> (einfache) SQL-Funktionen direkt in den query-tree eingeklebt
> und vom planner entsprechend besser behandelt werden können.

das wäre schön!

> Kannst Du. AFAIK gibt es ein Modul zum Zugriff auf shared memory.
> Du könntest einfach Deine Daten serialisieren und dort reinpacken.

davon gibt es eine Reihe, ja; aber beim Initialisieren werden die Daten
meist in den eigenen Speicher kopiert, und das ist Quatsch und kostet
natürlich viel Zeit.
Es müsste wie beim Apache/mod_perl die Möglichkeit geben, das beim
Startup zu laden und dann kriegt jeder bei jedem Fork alle Daten mit.

> Allerdings hast Du damit die gleichen Probleme zu bewältigen,
> wie üblicherweise auch beim session-Management (locking, etc).

das kommt noch hinzu, ja. Bei Schreibzugriffen zumimdest.

Ciao
Alvar

--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

-- Harald Fuchs <hf0923x(at)protecting(dot)net> wrote:

> Derzeit geistert in den englischsprachigen Mailinglisten die Idee
> herum, eigene SHM-Bereiche für beliebige Erweiterungen anzubieten,
> nicht nur für PL/Perl.

das hört sich ja -- ganz allgemein -- ganz gut an!

Ciao
Alvar

--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

Hallo,

-- Enrico Weigelt <weigelt(at)metux(dot)de> wrote:

> idR. mit jeder neuen connection.
> Wenn Du perl dazu bringen kannst, bestimmte Variablen innerhalb eines
> Prozesses persistent zu halten (also zwischen verschiedenen Aufrufen),
> dann kannst Du dort einfach ein Flag setzen.

aber eben nur innerhalb eines Prozesses. Ganz allgemein: wenn Du 10 MB an
Daten hast und 100 Verbindungen ... ;-)

> Mit pl/php geht das wunderschön: globale Variablen sind persistent
> (weil ja die engine nur einmal pro Prozess gestartet wird) und damit
> hast Du einen backend-weiten globalen Speicher. Eignet sich zB.
> gut nett fürs caching.

das geht garantiert auch mit Perl; aber eben bei beiden nur für jeweils
einen Prozess. Große Datenmengen lassen sich damit nicht speichern.

Bei mod_perl mache ich das anders: beim Start (vor dem Fork!) wird eine
Datenstruktur aufgebaut und dann können nachher alle Prozesse darauf
zugreifen. Solange es nur lesend ist bleibt es geshared; bei
Schreibzugriffen greift das Copy-on-Write vom Betriebssystem.

Ciao
Alvar

--
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

--On Freitag, Oktober 21, 2005 11:20:04 +0200 Enrico Weigelt
<weigelt(at)metux(dot)de> wrote:

> idR. mit jeder neuen connection.
> Wenn Du perl dazu bringen kannst, bestimmte Variablen innerhalb eines
> Prozesses persistent zu halten (also zwischen verschiedenen Aufrufen),
> dann kannst Du dort einfach ein Flag setzen.

Das geht ja bereits mit %_SHARED.
Eine Alternative hierzu wäre pgmemcache:

http://pgfoundry.org/projects/pgmemcache/

--
Thanks
Bernd