Bug in VACUUM FULL ?

Hi,

I am right now working on to get HOT and VACUUM FULL work
together. I hit upon a bug which I initially thought is
something that HOT has introduced. But I can reproduce
it with CVS HEAD as well.

Here is what I do: Create a table a simple table with
three columns and one index. Insert a single row in the
table.

CREATE TABLE test (a int, b int, c char(512));
CREATE UNIQUE INDEX testindx ON  test (a);
INSERT INTO test VALUES (1, 2, 'test');

Now, I continuosly UPDATE the same row with a simple
sql script using pgbench with two clients.

$ cat test.sql   
UPDATE test set b = b + 10 WHERE a = 1;
SELECT *, ctid FROM test;

$ ./pgbench -c 2 -t 50000 -f ./test.sql postgres

Now, I run VACUUM FULL on the table in a loop with 20
seconds sleep.

$ while (true); do
echo "VACUUM FULL START";
./install/bin/psql -c 'vacuum full verbose test;' postgres;
echo "VACUUM FULL COMPLETE";
sleep 20;
done;


After few seconds pgbench fails with the following output:

starting vacuum...end.
Client 1 aborted in state 0: ERROR:  could not read block 650 of 
relation 1663/11467/16401: read only 0 of 8192 bytes
Client 0 aborted in state 0: ERROR:  could not read block 649 of 
relation 1663/11467/16401: read only 0 of 8192 bytes
transaction type: Custom query
scaling factor: 1
number of clients: 2
number of transactions per client: 50000
number of transactions actually processed: 29445/100000
tps = 459.980394 (including connections establishing)
tps = 460.040423 (excluding connections establishing)


Is this something which has been reported earlier ? My first
guess would be some kind of race condition between the FSM
updates and the relation truncation.

Its too late for me to look into this now. If someone wants
to look into this, that would be great. I would otherwise
work on this tomorrow. Any clues/pointers are appreciated.


Thanks,
Pavan


EnterpriseDB    http://www.enterprisedb.com