From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | was: BUG #1466: syslogger issues |
Date: | 2005-02-21 10:18:19 |
Message-ID: | 4219B56B.2050509@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Magnus Hagander wrote:
>
>
>>>There is special code in the send_message_to_server_log
>>
>>function to make
>>
>>>sure it's written directly to the file.
>>
>>If the logger is complaining, it's quite possibly because it's
>>unable to
>>write to its file. Now that you mention it, doesn't this code go into
>>infinite recursion if write_syslogger_file_binary() tries to ereport?
Yes, apparently.
Actually, elog.c code should look like this:
if ((Log_destination & LOG_DESTINATION_STDERR) ...)
{
if (am_syslogger)
write_syslogger_file(buf.data, buf.len);
else
fwrite(buf.data, 1, buf.len, stderr);
}
This avoids unnecessary pipe traffic (which might fail too) and gettext
translation.
Next, the elog call in write_syslogger_file_binary will almost certainly
loop, so it should call write_stderr then (since eventlog is usually
fixed-size with cyclic writing, even in out-of-disk-space conditions
something might get logged).
3rd, I've been proposing to have redirect_stderr=true on by default at
least on win32 earlier, I still think this is reasonable.
Regards,
Andresa
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2005-02-21 16:23:18 | Re: Patch for disaster recovery |
Previous Message | Neil Conway | 2005-02-21 06:24:31 | Re: WIP: pl/pgsql cleanup |