> Peter Geoghegan <pg@bowt.ie> writes:
>> I agree with your conclusion, but I still think that it's slightly
>> ambiguous. There didn't seem to be an issue with sequences going
>> backwards -- the actual complaint was about there being multiple
>> versions of the same logical row visible simultaneously (sequences
>> were mentioned in passing). This is probably a case of tuples within a
>> HOT chain experiencing some kind of "resurrection". Though that in
>> itself doesn't prove much of anything.
> Yeah, I wondered about that, particularly in view of the multiple
> tuple-freezing bugs we've found. If the damage were in just one table
> I'd believe it for sure ... but I'm not sure I believe it across 5
> tables.
>
> But the bottom line is the same: update to 9.4.latest (which is *not*
> 12 btw), and double-check storage reliability.
>
> regards, tom lane
>
>
Before the issue, there was a data recovery operation (the data cluster
was restored), but it seems that data in tablespaces were not cleaned up
before the operation, do you think this could be the cause of the
duplicate keys issue?
It seems that it is not for us to fix the issue by deleting manually
duplicated data. Is it possible to restore the data cluster before the
issue and re-apply WAL?
Concerning the storage, we use data disk bay, it seems that our hardware
is quite reliable. But it seems that during the issue, no system error
was found, thus we will reconfirm that the system engineer.
Concerning the upgrade, is it possible to upgrade directly from the
minor version 9.4.4 to the latest minor version 9.4.14 without applying
all the minor versions in between? I guess that to upgrade one minor
version it only needs to stop PostgreSQL, then apply the binaries and
start PostgreSQL. Could you also confirm this?
Best regards
Henri Ky
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
