Using strace, I was able to determine that the logger process was
attempting to output its usual messages when an invalid SQL query was
issued.
As an experiment, I changed the value of log_directory in
postgresql.conf (to a directory which I had created in a different
partition than /var) and reloaded - issued a command which would
guarantee an error - voila, a new log file was created in that directory.
I then changed log_directory to its original value, reloaded, issued an
invalid query - and a new log file was created in the proper location.
Everything seems back to normal.
So my problem is solved, although I wish I had some idea what had caused
it in the first place.
Tom Lane wrote:
Lewis Kapell <lkapell@xxxxxxxxxxxxx> writes:
If I search the output of ps -ax for entries containing both "postgres:"
and "process" I get the following:
2259 ? Ss 0:03 postgres: logger process
Well, that looks reasonable. You might try strace'ing that process
while you do something that's certain to provoke a log entry
(maybe "SELECT 1/0;" in a psql session).
The only likely problem that I can think of at this point is that
SELinux might think the process shouldn't be allowed to write in
/var/log/postgres/, but I don't know why that would have just suddenly
started to be a problem after working before. Unless maybe someone
did a system-wide restorecon or some such.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
