Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-03-17 14:29:56 -0400, Tom Lane wrote:
>> [ scratches head ... ] If that's what's happening, isn't it a bug in
>> itself? Surely the WAL record ought to point at the tuple that was
>> locked.
> There's a separate XLOG_HEAP2_LOCK_UPDATED record, for every later tuple
> version, emitted by heap_lock_updated_tuple_rec(). This really is mind
> bendingly complex :(.
Ah, I see; so only the original tuple in the chain is at risk?
How about this:
This error caused updated rows to not be found by index scans, resulting in inconsistent query results
dependingon whether an index scan was used. Subsequent processing could result in constraint violations, since
thepreviously updated row would not be found by later index searches, thus possibly allowing conflicting rows to be
inserted. Since this error is in WAL replay, it would only manifest during crash recovery or on standby servers.
The improperly-replayed case most commonly arises when a table row that is referenced by a foreign-key
constraintis updated concurrently with creation of a referencing row; but it can also occur when any variant of
<command>SELECTFOR UPDATE</> is applied to a row that is being concurrently updated.
regards, tom lane