* reformated the current doc

* updated to the current state of discussion


git-svn-id: svn+ssh://svn.opensde.net/home/users/karasz/x5/x5dagon/trunk@5 471cc25b-571d-0410-8e29-1f4f9b506cef

doc/x5dagon.txt

@@ -1,27 +1,112 @@
-1. OS part
+TarDiBa - Database Server
+=========================
+
+
+Operating System
+----------------
+
 - filesystem, probably reiserfs (fast)
 - tweaked boot for high performance
 - tweaked kernel, highmem, disk access and stuff 
 
-2. database part
+
+Database System
+---------------
+
 - various maintanace scripts (for now using them for backups 
 and vacuuming)
 - jump to pg8 
-- autovacuuming? maybe we should disable.
-- implementing a logging facility to RAM, flushing logs in 
-background to disk?
 
-3. backup part
+
+Autovacuuming
+~~~~~~~~~~~~~
+
+- autovacuuming has to be disabled with the postgresql.conf 
+
+
+Logging
+~~~~~~~
+
+Abstract
+^^^^^^^^
+
+postgresql has a logging facility that drops every statement to log
+before it get's executed.
+in certain conditions those logs are of very big interest.
+legal issues and profiling issues.
+
+
+Problem
+^^^^^^^
+
+problem is that if i enable that systems goes 10 times slower because
+of the huge statements that has to be written to disc.
+
+On a bussy server they can easily reach 10th of MB per day.
+30-40 but that is quite rare
+usualy under 10MB
+
+
+Solution
+^^^^^^^^
+
+- implementing a logging facility to RAM, flushing logs in
+  background to disk
+
+- usually i am only interested in those statements
+
+we have to consider to flush the logs from the ramdisk if we restart
+pg perhaps
+
+
+Tasks
+^^^^^
+
+- we need to test a postgresql.conf option that only logs statements
+  that take more time than a specified period (i.e. 5min.)
+
+- problem is that that option doesn't work too well like the option
+  to kill iddle statements
+
+- problem is that pg does not recognize blocked processes like the
+  ones which are iddle in transaction. an iddle in transaction proces
+  blocks the whole db (no selects, no updates, no nothing). the only way
+  out of it is to kill -9 the process
+
+- killing postgresql processes
+	- postgresql has 2 kinds of processes (the parent postmaster
+	  process which is allways active and child postmaster processes
+	  which are born from the master when it receives a statement
+	- problem is that childs are forks so whenever i kill a child,
+	  all childs die that sucks somehow
+	- so instead of killing childs we usualy restart the postmaster but
+	  that has to have another solution too, just that i was unable to
+	  find it
+	- is there any possib to kill a forked child withoput killing all
+	  childs? (maybe there are some kill statement options for that)
+	- normally each child should have an own PID
+	- i use kill -9 $PID
+	- most probably the parent "thinks" there are problems if one
+	  child dies and kills them all
+	- next thing is that only the master postmaster is alive. i
+	  couldn't get a concludent answer from #postgresql. all that i
+	  got was 'Don't kill -9 postmaster.
+
+
+Backup System
+-------------
+
 - backup is done by shell scripts and cron (change? not likely)
 - backups on other machines (over scp for other linux hosts, samba 
 for 'secure' Windows2000???, eventually a pro backup app although i 
 don't think it is necessary, maybe for whole system recovery)
 
-4. spying, early warning, notification part.
+System Monitoring and Notification
+----------------------------------
+
 - monitoring disk space, backup files dimensions, excerpts from 
 certain log files, system status and stats (cpu usage, ram etc), monitoring 
 pg sessions because the internal pg monitor sucks, we need a good policy on 
 killing iddle sessions and runaway processes. 
 
 
-New name Proposal... X5Dagon looks akward, what about Tardiba?