I wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> We could resolve both of these issues by changing the semantics of
>>> OprUpdate so that it unconditionally does a CommandCounterIncrement
>>> after each update that it performs. IMO that would be a lot simpler
>>> and more bulletproof; it'd allow removal of a lot of these
>>> overly-tightly-reasoned cases.
>> I tried this, but it did not seem to work.
> Odd. If you post the revised patch, I'll try to chase down what's wrong.
After playing with this, I'll bet you forgot that RemoveOperatorById would
need to re-fetch the target tuple if it got updated. We could
alternatively fix that by skipping updates on the tuple due to be deleted,
but that would convolute the logic in OperatorUpd, which didn't seem
worthwhile to me.
I found some other stuff needing fixing (mostly typos in comments) and
also realized that we don't really need to bother with heap_modify_tuple
at all. I pushed it with those fixes.
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
