On Fri, Mar 25, 2016 at 12:39 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Cool. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
