Re: alter table only ... drop constraint broken in HEAD

On Thu, Oct 6, 2011 at 07:24, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Oct 5, 2011 at 10:29 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Oct 5, 2011 at 5:53 PM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
>>> tldr:
>>>
>>> Seems to be broken by
>>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4da99ea4231e3d8bbf28b666748c1028e7b7d665
>>> :
>>> commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665
>>> Author: Robert Haas <rhaas(at)postgresql(dot)org>
>>> Date:   Mon Jun 27 10:27:17 2011 -0400
>>>
>>>    Avoid having two copies of the HOT-chain search logic.
>>

> Oh, I see the problem, and I now agree that it's the DROP CONSTRAINT
> code that is buggy.

Want me to roll this fix in as part of the alter table only constraint
patch? Or keep it split out? We might want to backpatch to at least
8.3 where HOT was introduced (yes looks like the bug existed back
then). I suppose its a fairly narrow chance to hit this bug so I could
see the argument for not back patching...

> I took a look around for other places that might have this same
> problem and didn't find any, but I'm not too confident that that means
> there are none there, since there are a fair number of things that can
> call CommandCounterIncrement() indirectly.

I skimmed for the direct easy to find ones as well. Didn't see any
other than the one you note below.

>  shdepReassignOwned() does
> a direct CCI from within a scan, but ISTM that any update we do there
> would produce a new tuple that doesn't match the scan, so that should
> be OK.

Well its on purpose so I hope its ok :-)