The following is a simple test case to demonstrate a backend not closing a file descriptor to wal file, under Linux 2.4.17 and PG 7.1.3
In session1: Using psql <db> cmd, create a table. Perform an insert on that table. In session2: Issue psql <db> run "ls -l /proc/*/fd/* | grep pg_xlog" This will list all of the backends which have open any wal files. (The process for session1: can be observed at this point.) In session3: Generate lots of large transactions that force a new wal file to be created and used. Once the new wal file has started to be used by the actions performed in session3, stop all activity. After the CHECKPOINT_TIMEOUT time has been reached, the backend which had the original pqsl connection (session1:) now has had its wal file deleted from underneath it. running "ls -l /proc/*/fd/* | grep pg_xlog" will show that. If the database is in its own partition, running "df" and "du -c" will whow differing totals. To conclude, if you have many clients whose backends have infrequent write accesses and then long periods of inactivity, but whose connection to the database is left open, and other backends that are active which march on and create new wal files, many "(deleted)" wal can be created which are ONLY cleared up, with the closing of the backend or when another write access on the db from that backend. We believe that in 7.2, this issue can be avoided by precreating the a set number of wal files, and new wal file will rename the older one. (The file descriptors to these files will point to the new renamed wal file, rather than the old name.) As another point, is there a way to TURN OFF WAL completely???? Francis Reader ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Imerge Limited Tel :- +44 (0)1954 783600 Unit 6 Bar Hill Business Park Fax :- +44 (0)1954 783601 Saxon Way Web :- http://www.imerge.co.uk Bar Hill Cambridge CB3 8SL United Kingdom ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
