postgresql.conf ???

Ich habe eine kleines Verständnis Problem.

Die Zeilen die mit #foo in dem File postgresql.conf stehen sind die nun gültig und nur default Werte oder sind die nicht gültig.

Wenn nicht gültig welche Werte nimmt er denn als Standartwerte.

Z.B. bei Loggs

#---------------------------------------------------------------------------

ERROR REPORTING AND LOGGING

#---------------------------------------------------------------------------

- Where to Log -

#log_destination = ‘stderr’ # Valid values are combinations of

stderr, syslog and eventlog,

depending on platform.

This is used when logging to stderr:

#redirect_stderr = off # Enable capturing of stderr into log

files

(change requires restart)

These are only used if redirect_stderr is on:

#log_directory = ‘pg_log’ # Directory where log files are written

Can be absolute or relative to PGDATA

Wenn ich nun einen Ordner pg_log anlege und habe dieses Einträge, dann schreibt er die Logs in den Ordner pg_log.

Eigentlich sollte der Eintrag doch so sein oder ??

log_destination = ‘stderr’
redirect_stderr = on
log_directory = ‘pg_log’

Also jetzt bin ich überfragt.

Zeilen mit # am Anfang sind generell Kommentare. In der config stehen konfigurierbare Variablen, die ohne Angabe eines Wertes
einen vordefinerten Wert haben, halt kommentiert drin. Dann greift der Default. Gefällt der Dir nicht, kannst Du das ändern. Ich kopiere die Zeile, entferne das # und ändere den Wert.


Andreas

genua, aber warum schreibt er dann in pg_log, wenn dieser Wert laut Kommentar nur greift, wenn stderr und redirect_stderr = on ???

Ob die Werte in der Config mit einem # als Kommentar drin stehen oder gar nicht dort stehen würden, macht keinen Unterschied.

Es hat sich allerdings eingebürgert, in der Config den Defaultwert, den das jeweilige Programm annimmt, wenn nichts gegeben ist, mit hinzuschreiben. Damit du als Benutzer sehen kannst, welchen Wert die Datenbank sowieso wählt, wenn du nichts angibst. Ist halt eine schöne Hilfe.

Wenn du das ändern möchtest, kannst du an der Stelle auch einfach das # entfernen und deinen Wert eintragen, musst dir also nicht die gesamte Info neu aus der Hilfe zusammensuchen. Ich für meinen Teil kopiere die betreffende Zeile dann, lasse das Original stehen und schreibe eine Zeile da drunter dann meinen geänderten Wert ohne # hin.

ads alles was du schreibst ist richtig, ich mache das ganz genau so, halt linux spezifisch, alte zeile drin lassen nächste Zeile auskommentiert und mit Wert.

Was ich aber nicht Verstehe ist dies.

This is used when logging to stderr:

#redirect_stderr = off # Enable capturing of stderr into log

files

(change requires restart)

These are only used if redirect_stderr is on:

#log_directory = ‘pg_log’ # Directory where log files are written

Hier ist der Default Wert für redirect_stderr = off
Also dürfte er nicht in log_directory = ‘pg_log’ schreiben sondern müsste z.B. unter /var7/log/postgresql die Logs abspeichern.

Aber er speichert trotzdem in pg_log, auch wenn redirect_stderr = off da steht.

Setz doch mal die Werte explizit so, wie du es haben möchtest. Also: Zeile kopieren, Kommentar wegnehmen, Wert so eintragen wie gewünscht. DB neustarten, schauen, was passiert.

So ich habe eben einen neuen Cluster erzeugt, meine Config angepasst und die Daten hinein kopiert, die DB gestartet und nun macht Sie genau das was ich will.
Keine Ahnung was bei der Anderen Datei falsch war. Jetzt ist Sie im Nirvana gelandet.

Danke für eure Hilfe

Hi Andreas,

ich habe das Logging mal scharf geschaltet. Wie du vermutet hast, scheint der Fehler nichts mit PG zu tun zu haben. Folgendes steht in der Log:

2009-01-06 08:00:38 STATEMENT: SELECT “picture” ,“picturename” FROM “public”.“spareparts_details” WHERE (“id_spareparts_details” = 448187 )

2009-01-06 08:00:38 DEBUG: StartTransaction

2009-01-06 08:00:38 STATEMENT: SELECT “picture” ,“picturename” FROM “public”.“spareparts_details” WHERE (“id_spareparts_details” = 448187 )

2009-01-06 08:00:38 DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 12837444/1/0, nestlvl: 1, children: <>

2009-01-06 08:00:38 STATEMENT: SELECT “picture” ,“picturename” FROM “public”.“spareparts_details” WHERE (“id_spareparts_details” = 448187 )

2009-01-06 08:00:38 DEBUG: CommitTransactionCommand

2009-01-06 08:00:38 STATEMENT: SELECT “picture” ,“picturename” FROM “public”.“spareparts_details” WHERE (“id_spareparts_details” = 448187 )

2009-01-06 08:00:38 DEBUG: CommitTransaction

2009-01-06 08:00:38 STATEMENT: SELECT “picture” ,“picturename” FROM “public”.“spareparts_details” WHERE (“id_spareparts_details” = 448187 )

2009-01-06 08:00:38 DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 12837444/1/0, nestlvl: 1, children: <>

2009-01-06 08:00:38 STATEMENT: SELECT “picture” ,“picturename” FROM “public”.“spareparts_details” WHERE (“id_spareparts_details” = 448187 )

2009-01-06 08:00:38 DEBUG: StartTransactionCommand

Hier kann man nichts von einem Fehler erkennen. Die selbe Prozedur geht mit MySQL einwandfrei. Was ist bei diesem Datentyp anders? Nehme ich die falschen ODBC-Treiber?

LG Sylvio

Meine Vermutungen stimmen einklich fast immer. Heute vermute ich, Du hast Dich im falschen Thread verlaufen…

[/quote]
Hier kann man nichts von einem Fehler erkennen. Die selbe Prozedur geht mit MySQL einwandfrei. Was ist bei diesem Datentyp anders? Nehme ich die falschen ODBC-Treiber?

LG Sylvio[/QUOTE]

Dein Log enthält nur Selects, Deine Fehler kommen aber (vermutlich) beim Insert. Ich habe mit Bildern und BYTEA selber noch nichts gemacht, aber der prinzipielle Weg ist, aus einer Binärdatei mittels encode() eine ASCII-Repräsentation zu machen und diese darin zu speichern.

Andreas

Oh ja, schuldigung - war im falschen Thread. Habe es aber noch ma im richtigen gepostet.

hier weiter: http://www.pg-forum.de/externe-schnittstellen/3066-bild-bytea-ber-ms-access.html

DANKE Sylvio