Re: Current log files when rotating?
От | Greg Smith |
---|---|
Тема | Re: Current log files when rotating? |
Дата | |
Msg-id | Pine.GSO.4.64.0811102302320.26271@westnet.com обсуждение исходный текст |
Ответ на | Re: Current log files when rotating? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Mon, 10 Nov 2008, Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> It seems that there is enough need for this feature, that it has been >> implemented multiple times -- but most of them will fail in corner >> cases. Seems an obvious candidate for an in-core function ... > > ... which will still fail in corner cases. Not to mention the race > condition when the logger has just/is about to switch. As you can see from the responses here, barring an official way people are just going to hack up their own solutions that are even more error-prone than that. A core implementation that has a documented potential for a race condition would still be a large improvement over nothing at all here. As long as it's atomic enough to give you either the old name or the new one, that's good enough. In a typical log-reading application, you're going to poll the server to check the file name more regularly than it can possibly change. The fact that you might get a file name that will go stale almost immediately afterwards isn't a problem. You'll keep reading from the old file, it won't have anything new in it for some number of minutes or hours. When you next check the server, you'll see a new file listed, then start fresh on that one until you catch up. In some cases, the fact that the file name changed and the server is working on a new one is actually the trigger you're looking for--at that point you know it's safe to run analysis on the old file because it's complete. I can think of some better ways to slice that switching time downward (NOTIFY comes to mind), but I'd bet most admins wouldn't use a more sophisticated one even if it were available--too much work compared to something that just polls and looks for changes. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-general по дате отправления: