From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Joshua Tolley <eggyknap(at)gmail(dot)com>, jd <jd(at)commandprompt(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: syslog_line_prefix |
Date: | 2009-09-28 19:43:29 |
Message-ID: | 4AC111E1.3030105@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera wrote:
> Tom Lane escribió:
>
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>
>>> Tom Lane escribió:
>>>
>>>> This is the same issue already raised with respect to syslog versus
>>>> syslogger, ie, some people would rather lose log data than have the
>>>> backends block waiting for it to be written.
>>>>
>>> That could be made configurable; i.e. let the user choose whether to
>>> lose messages or to make everybody wait.
>>>
>> Hmm, I guess I missed where you proposed an implementation that would
>> support that?
>>
>
> syslog uses a nonblocking file descriptor without a retry loop to
> implement their logic. I see no reason we couldn't do that ourselves.
> Mixing it with regular blocking code could turn out to be nontrivial,
> but I don't think it's impossible.
>
>
Well, for CSV logs it's a complete non-starter. We go to quite a deal of
trouble to ensure we don't miss messages, because if we do the CSVs will
be hopelessly corrupted.
Frankly, if you're generating so much log output that blocking is going
to become an issue you should probably just be using syslog on Unix anyway.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Stef Walter | 2009-09-28 20:04:26 | Re: pg_hba.conf: samehost and samenet [REVIEW] |
Previous Message | Tom Lane | 2009-09-28 19:31:50 | Re: [PATCH] DefaultACLs |