Re: csvlog gets crazy when csv file is not writable
От | Tom Lane |
---|---|
Тема | Re: csvlog gets crazy when csv file is not writable |
Дата | |
Msg-id | 15916.1535313071@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: csvlog gets crazy when csv file is not writable (Dmitry Dolgov <9erthalion6@gmail.com>) |
Список | pgsql-bugs |
Dmitry Dolgov <9erthalion6@gmail.com> writes: >> On Sun, 26 Aug 2018 at 00:39, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> What the attached patch does about that is to redirect CSV-format >> output to syslogFile if we get CSV output when csvlogFile isn't open. >> The only other plausible answer I can see is to drop such output on >> the floor, and that seems pretty unfriendly. > Yes, probably it's the only plausible answer for now. But then I would argue > that in the ideal world we will redirect output, that we can't write to > csvlogFile, to syslogFile in non-csv format, which will be less surprising. It > would require to move the actual csv formatting logic to the syslogger, or to > let backends to know somehow that csv log is not available at this moment > (although I assume both options are not particularly realistic). Yeah, something like that is what would have to happen. The second option is a complete nonstarter though: (a) there's no feedback path and (b) even with feedback, there'd be race conditions. It's conceivable that we could push the formatting work down to the syslogger; but I think that would be a net loss in both reliability and performance --- remember the syslogger is a bottleneck for logging activities, since it's inherently not parallel. Given that this is such a corner-case scenario, and one that generally implies a DBA screwup that needs to be fixed, I don't want to expend a lot of work and potentially reduce performance in order to make it cleaner. regards, tom lane
В списке pgsql-bugs по дате отправления: