Re: csvlog gets crazy when csv file is not writable
От | Dmitry Dolgov |
---|---|
Тема | Re: csvlog gets crazy when csv file is not writable |
Дата | |
Msg-id | CA+q6zcUHivMWerY6_aMB-T76zyU3egJz8A6OwfLH_FCfKYR=5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: csvlog gets crazy when csv file is not writable (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: csvlog gets crazy when csv file is not writable
|
Список | pgsql-bugs |
> On Sun, 26 Aug 2018 at 00:39, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > At postmaster startup, we can open csvlogFile if requested and fail if > we can't, just as for syslogFile. And if we fail to make a rotation, > it's okay to keep writing to the old file, just as for syslogFile. > But we have to allow for Log_destination to change after startup, > and that means we might need to open csvlogFile when it wasn't open > before, and we can't just quit if we fail. I agree, sounds great. > 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).
В списке pgsql-bugs по дате отправления: