Skip site navigation (1) Skip section navigation (2)

Re: Possible Bug? TEST CASE

From: Francis Reader <freader(at)imerge(dot)co(dot)uk>
To: "'pgsql-bugs(at)postgresql(dot)org'" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Possible Bug? TEST CASE
Date: 2002-07-16 14:43:03
Message-ID: C0D45ABB3F45D5118BBC00508BC292DBA9440C@imgserv04 (view raw or flat)
Thread:
Lists: pgsql-bugs
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 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 



Responses

pgsql-bugs by date

Next:From: Joe ConwayDate: 2002-07-16 16:20:20
Subject: Re: Bug #712: Documentation Section 3.4 Binary Strings
Previous:From: Tom LaneDate: 2002-07-16 13:47:24
Subject: Re: pgDataRead

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group