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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
