On Mon, 10 Nov 2008, Tom Lane wrote:
Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
