On Fri, Mar 25, 2016 at 12:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane <tgl@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