On Thu, Sep 28, 2017 at 1:20 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Alvaro Herrera wrote:
>
>> Odd that it's not fixed. I guess there's still some more work to do
>> here ...
>
> Maybe what this means is that we need to do both Dan's initially
> proposed patch (or something related to it) apart from the fixes already
> pushed. IOW we need to put back some of the "tupkeep" business ...
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)
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
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers