This is not really accurate: "This error allowed multiple versions of the same row to become visible to queries, resulting in apparent duplicates. Since the error is in WAL replay, it would only manifest during crash recovery or on standby servers."
I think the idea is coming from what the second sentence below is getting at but it may be too complex to explain in a release note: The error causes some rows to disappear from indexes resulting in inconsistent query results on a hot standby depending on whether indexes are used. If the standby is subsequently activated or if it occurs during recovery after a crash or backup restore it could result in unique constraint violations as well. I would consider adding something like "For the problem to occur a foreign key from another table must exist and a new row must be added to that other table around the same time (possibly in the same transaction) as an update to the referenced row" That would help people judge whether their databases are vulnerable. If they don't have foreign keys or if they have a coding pattern that causes this to happen regularly then they should be able to figure that out and possibly disable them if they can't update promptly. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
