Andres Freund <> 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 (
To make changes to your subscription:

Reply via email to