SPELL=pglogd VERSION=2.3 SOURCE=$SPELL-$VERSION.tar.gz SOURCE_DIRECTORY=$BUILD_DIRECTORY/$SPELL-$VERSION SOURCE_URL[0]=http://www.digitalstratum.com/download/$SPELL-2.3.tar.gz WEB_SITE=http://www.digitalstratum.com/pglogd/index.php ENTERED=20020506 SOURCE_HASH=sha512:3152affc22f3123da46d485f72c8abfb26cd51202abe35e469996ccabf1297b3a963b8ed5c264005bc2625c8df5ecf4c5f5baff2481ba0b2358ebfcd746cd126 KEYWORDS="web database http" SHORT="pgLOGd takes web server log entries and sends them to a database." cat << EOF pgLOGd, simply put, is a program that takes web server log entries and sends them to a database. It is called pgLOGd because of the database it was designed to function with, PostgreSQL. Features: 1. Database logging. The primary feature that gave pgLOGd its name. Instead of writing log entries to a file, pgLOGd writes them to a database. The advantages of this method over logging to a file are explained in the README. 2. Fast. pgLOGd was designed to be as fast as possible, just as if the web server was logging to a file. 3. Robust. pgLOGd is smart and will attempt to recover from errors, network failures, and database problems when possible. 4. Fall-Back-Logging. This is part of the robustness of pgLOGd. If the connection to the database fails for any reason, pgLOGd will begin to write the log entries to a temporary overflow file. pgLOGd will then attempt to re-establish the database connection every 30 seconds (configurable) until it restores the database connection. At this time pgLOGd will begin processing the overflow file entries to the database during idle moments. The overflow file will also be used when entries are coming in from the web server faster than they can be set to the database, which is how pgLOGd achieves its "as fast as writing to a file" speed. Then during slow periods the entries will be processed from the overflow file and sent to the database. 5. Non-blocking. This is also what allows pgLOGd to be extremely responsive and fast, it never waits for anything to finish. Simply put, pgLOGd will ask the database to store an entry, then come back later to see if it was successful, instead of waiting around for the database to finish. This allows pgLOGd to continue processing entries from the web server while previous entries are being written to the database. The non-blocking functionality of pgLOGd is also one of the reasons why PostgreSQL was chosen, because of its excellent asynchronous connection and query processing provided by its C interface. 6. Small system overhead and resource usage. pgLOGd runs as a single daemon process and typically uses less that 128K of memory. 7. Flexible. pgLOGd was designed to be configurable and as system and web server independent as possible. EOF