From: Karl Schnaitter <karlsch@soe.ucsc.edu>
To: pgsql-patches@postgresql.org
Subject: fixing bug in combocid.c
Date: Fri, 29 Aug 2008 15:00:04 -0700
Message-ID: <48B87164.4050802@soe.ucsc.edu> (raw)
This patch is for a bug in backend/utils/time/combocid.c.
In HeapTupleHeaderAdjustCmax, the code makes the incorrect assumption
that the raw command id corresponds to cmin, when the raw command id can
in fact be a combo cid. It needs to be fixed to call
HeapTupleHeaderGetCmin to get cmin. That's all there is to my patch, but
read on for more details.
One thing that can happen is that multiple subtransactions may delete a
tuple and each abort. Each subtransaction (except the first one) will
store a combo cid that uses another combo cid as cmin. Then when cmin is
accessed by a later operation, HeapTupleHeaderGetCmin will return the
previous combo cid. In unlucky situations, the bogus cmin will be so
high that it looks like the tuple was inserted in the future.
I have pasted an example below to show how things can go wrong. The
second SELECT leaves out some tuples because their stored cmin is
actually a large combo cid. The third SELECT gives correct results
because the inserting transaction committed, so the command id is
ignored. The script file with these commands in in the attachment, and I
think it could make for a valuable regression test.
Side note: Another idea for a fix would be to have tqual.c change a
combocid to a simple cmin when it does a time qual check and sees that
the deleting subtransaction aborted. This is no good because it requires
a write lock to change two header fields atomically, namely the
HEAP_COMBOCID hint and t_cid. There are probably other issues, but this
seems like a show-stopper.
The one-line patch is in the attachment. It gives correct behavior on my
test case. This is my first patch; I hope I did it right!
Thanks!
Karl Schnaitter
test=# CREATE TABLE tab(a INT);
CREATE TABLE
test=# BEGIN;
BEGIN
test=# INSERT INTO tab VALUES(1);
INSERT 0 1
test=# INSERT INTO tab VALUES(2);
INSERT 0 1
test=# INSERT INTO tab VALUES(3);
INSERT 0 1
test=# SAVEPOINT s; DELETE FROM tab; ROLLBACK TO SAVEPOINT s;
SAVEPOINT
DELETE 3
ROLLBACK
test=# SELECT a FROM tab;
a
---
1
2
3
(3 rows)
test=# SAVEPOINT s; DELETE FROM tab; ROLLBACK TO SAVEPOINT s;
SAVEPOINT
DELETE 3
ROLLBACK
test=# SAVEPOINT s; DELETE FROM tab; ROLLBACK TO SAVEPOINT s;
SAVEPOINT
DELETE 3
ROLLBACK
test=# SAVEPOINT s; DELETE FROM tab; ROLLBACK TO SAVEPOINT s;
SAVEPOINT
DELETE 3
ROLLBACK
test=# SELECT a FROM tab;
a
---
1
(1 row)
test=# COMMIT;
COMMIT
test=# SELECT a FROM tab;
a
---
1
2
3
(3 rows)
test=# DROP TABLE tab;
DROP TABLE
Attachments:
combocid.tgz (application/x-gzip, 710B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: karlsch@soe.ucsc.edu
Subject: Re: fixing bug in combocid.c
In-Reply-To: <48B87164.4050802@soe.ucsc.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox