Peter Geoghegan wrote:
> We certainly do still see wrong answers to queries here:
>
> postgres=# select ctid, xmin, xmax, * from t;
> ctid | xmin | xmax | id | name | x
> -------+-------+------+----+------+---
> (0,1) | 21171 | 0 | 1 | 111 | 0
> (0,7) | 21177 | 0 | 3 | 333 | 5
> (2 rows)
>
> postgres=# select * from t where id = 3;
> id | name | x
> ----+------+---
> 3 | 333 | 5
> (1 row)
>
> postgres=# set enable_seqscan = off;
> SET
> postgres=# select * from t where id = 3;
> id | name | x
> ----+------+---
> (0 rows)
Yeah, oops.
> FWIW, I am reminded a little bit of the MultiXact/recovery bug I
> reported way back in February of 2014 [1], which also had a HOT
> interaction that caused index scans to give wrong answers, despite
> more or less structurally sound indexes.
>
> [1] https://www.postgresql.org/message-id/CAM3SWZTMQiCi5PV5OWHb+bYkUcnCk=O67w0cSswPvV7XfUcU5g@mail.gmail.com
Thanks for the reference. I didn't remember this problem and it's not
(wasn't) in my list of things to look into. Perhaps these are both the
same bug.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers