diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2006-05-19 16:30:50 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2006-05-19 16:30:50 +0000 |
| commit | a2e7036909d65a7ad3894360ccb7a1dc0fab4279 (patch) | |
| tree | c5aa0de31dd15154a4994bffb45c055bf8dbc10c /src/backend/commands/copy.c | |
| parent | f939bdcafe03b1b34c48bb88241fff0dca0dec50 (diff) | |
| download | postgresql-a2e7036909d65a7ad3894360ccb7a1dc0fab4279.tar.gz postgresql-a2e7036909d65a7ad3894360ccb7a1dc0fab4279.zip | |
Fix nasty bug in nodeIndexscan.c's detection of duplicate tuples during
a multiple (OR'ed) indexscan. It was checking for duplicate
tuple->t_data->t_ctid, when what it should be checking is tuple->t_self.
The trouble situation occurs when a live tuple has t_ctid not pointing to
itself, which can happen if an attempted UPDATE was rolled back. After a
VACUUM, an unrelated tuple could be installed where the failed update tuple
was, leading to one live tuple's t_ctid pointing to an unrelated tuple.
If one of these tuples is fetched by an earlier OR'ed indexscan and the other
by a later indexscan, nodeIndexscan.c would incorrectly ignore the second
tuple. The bug exists in all 7.4.* and 8.0.* versions, but not in earlier
or later branches because this code was only used in those releases. Per
trouble report from Rafael Martinez Guerrero.
Diffstat (limited to 'src/backend/commands/copy.c')
0 files changed, 0 insertions, 0 deletions