Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Roma Sokolov <sokolov(dot)r(dot)v(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Женя Зайцев <zevlg(at)yandex(dot)ru>
Subject: Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
Date: 2016-03-25 16:39:16
Message-ID: 13807.1458923956@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-03-25 16:47:02 Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.
Previous Message Artur Zakirov 2016-03-25 16:25:46 Re: unexpected result from to_tsvector