I've had multiple complaints of apparent data loss on 9.3.2 customer databases. There are 2 total, both complaints from the past week, one of which I was able to confirm. The customer's complaint is that certain rows are either visible or invisible, depending on whether an index scan is used or a sequential scan (I confirmed this with an EXPLAIN ANALYZE). The expectation of the customer is that the rows should always be visible, because he didn't delete them. These are trivial queries on single trivial tables, but they have foreign keys.
It appears from our internal records that the database that I confirmed the issue on has always been on 9.3.2 (the heap files have only been touched by 9.3.2 binaries, although there is more than one timeline). I cannot swear that this was never on an earlier point release of 9.3, but it is considered quite unlikely. When I ran a manual VACUUM FREEZE, I could no longer reproduce the issue (i.e. the index scan and sequential scan both subsequently indicated that the row of interest was not visible, and so are at least in agreement). To me this suggests a problem with MultiXacts. However, I was under the impression that the 9.3.3 fix "Rework tuple freezing protocol" fixed an issue that could not manifest in such a way, and so it isn't obvious to me that this is a known bug. A reading of the 9.3.3 release notes offers no obvious clues as to what the problem might be. Apart from the freezing rework, and the "Account for remote row locks propagated by local updates" item, nothing jumps out, and it isn't obvious to me how even the most pertinent two items from *.3 might address relate to this. Have I missed something? Is this likely to be worth debugging further, to determine if there is an undiscovered bug? If so, I'm sure I can recover a copy of the data as it was before and reproduce the problem. I think that since this database was (very probably) always 9.3.2, we would not have run the vacuum/vacuum_freeze_table_age amelioration promoted for those upgrading to that point release (promoted in the *.2 release notes). On this database, as of right now: txid_current ────────────── 6242282 (1 row) -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers