Greg Stark <st...@mit.edu> writes:
> 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.
Hm ... "rows disappearing from indexes" might make people think that
they could fix or mitigate the damage via REINDEX. That's not really
true though is it? It looks to me like IndexBuildHeapScan will suffer
an Assert failure in an assert-enabled build, or build a bogus index
if not assert-enabled, when it comes across a "heap-only" tuple that
has no parent.
I'm thinking we'd better promote that Assert to a normal runtime elog.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
