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.


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:

Reply via email to