On Thu, Sep 28, 2017 at 1:20 PM, Alvaro Herrera <alvhe...@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=o67w0csswpvv7xfuc...@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
