           SPELL=pglogd
         VERSION=2.2beta
          SOURCE=$SPELL-$VERSION.tar.gz
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$SPELL-$VERSION
   SOURCE_URL[0]=http://www.digitalstratum.com/pglogd/pglogd-2.2beta.tar.gz
        WEB_SITE=http://www.digitalstratum.com/pglogd/index.php
         ENTERED=20020506
         UPDATED=20020509
     SOURCE_HASH=sha512:74c7f64987a5718c5ae83ba7c2eaad075d60877c18d490b708f1c9a963565ad613038fb91f703140c7508c84463bd659e7538b3f88eb7523417b84b51fe9d82b
        KEYWORDS="web database http"
       BUILD_API=1
           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
