Re: Possible Bug? TEST CASE

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~