Possible bug in new VACUUM code
Hi,
I just stumbled over a very hard to reproduce error. Running
a "VACUUM ANALYZE <table>" concurrently to a database heavy
under load caused a SELECT ... FOR UPDATE with full primary
key qualification to return multiple results from that table.
The table contains only a few rows which receive ton's of
updates.
System is 7.2B3 under Linux.
Will try to produce a test case, just to let ppl know early.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck <janwieck@yahoo.com> writes:
I just stumbled over a very hard to reproduce error. Running
a "VACUUM ANALYZE <table>" concurrently to a database heavy
under load caused a SELECT ... FOR UPDATE with full primary
key qualification to return multiple results from that table.
Urgh. But I am not sure that you should be pointing the finger at
VACUUM. It doesn't move any tuples around (at least not in ctid
terms), so how could it possibly produce multiple tuple images in
another scan? My early bet is that the problem is not directly
related to VACUUM.
Post as soon as you have any more info ... remember there are lots
of eyeballs out here ...
regards, tom lane
Jan Wieck wrote:
Hi,
I just stumbled over a very hard to reproduce error. Running
a "VACUUM ANALYZE <table>" concurrently to a database heavy
under load caused a SELECT ... FOR UPDATE with full primary
key qualification to return multiple results from that table.
The table contains only a few rows which receive ton's of
updates.System is 7.2B3 under Linux.
Will try to produce a test case, just to let ppl know early.
Can you post an explain plan for the query along with a "\d" of the table?