Andres Freund <and...@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 depending on whether an index scan was
used. Subsequent processing could result in constraint violations,
since the previously 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
constraint is updated concurrently with creation of a referencing row;
but it can also occur when any variant of <command>SELECT FOR UPDATE</>
is applied to a row that is being concurrently updated.
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
