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@setonhome.org> 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