Pavan Deolasee wrote:
>
> Thanks a lot, Tom. It seems to work fine for me. I will do some
> more tests and report if I see any issue.
>
The problem mentioned before is hard to reproduce with the
suggested change, but its not completely gone away. I have
seen that again on CVS HEAD with the patch applied.
I am facing another issue with VACUUM FULL. This
problem gets reproduced with HOT very easily, but takes
few attempts to reproduce with CVS HEAD, but it
certainly exists.
This time I am using pgbench. All tables but "history" are
created with fillfactor=50
Now, I start running pgbench with scale factor of 10 and 40
clients and 10000 txns/client. After few minutes, I start
running VACUUM FULL on tellers and branches, every 10 seconds.
After a while, all pgbench clients fail with the following
errors:
Client 1 aborted in state 11: ERROR: duplicate key violates unique
constraint "branches_pkey"
Client 30 aborted in state 11: ERROR: duplicate key violates unique
constraint "branches_pkey"
Client 39 aborted in state 11: ERROR: duplicate key violates unique
constraint "branches_pkey"
Client 7 aborted in state 11: ERROR: duplicate key violates unique
constraint "branches_pkey"
Next run of VACUUM FULL gives the following error:
WARNING: index "branches_pkey" contains 15 row versions, but table
contains 12 row versions
HINT: Rebuild the index with REINDEX.
Has this been reported earlier ? IIRC Tom mentioned in one of the
emails that Merlin has reported some problem related
to "duplicate key violation". Tom, could this be related ?
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
