Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date
Msg-id CAM3SWZT=HptrGyihZiyT39sPBhp+CXOTW=MhNFzXiLf-Jh4QVA@mail.gmail.com
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Peter Geoghegan <pg@heroku.com>)
Responses Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Thu, Dec 18, 2014 at 9:31 AM, Peter Geoghegan <pg@heroku.com> wrote:
>> So I think there needs to be some kind of logic to de-recognize the table
>> alias "foo".
>>
>> Once I rewrote the query to use TARGET and EXCLUDED correctly, I've put this
>> through an adaptation of my usual torture test, and it ran fine until
>> wraparound shutdown.  I'll poke at it more later.
>
> Oops. I agree with your diagnosis, and will circle around to fix that
> bug in the next revision

Attached patch fixes the bug. I'm not delighted about the idea of
cutting off parent parse state (the parse state of the insert) within
transformUpdateStmt() only once we've used the parent state to
establish that this is a "speculative"/auxiliary update, but it's
probably the path of least resistance here.

When this is rolled into the next version, there will be a testcase.

Thanks
--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: Adam Brightwell
Date:
Subject: Re: Role Attribute Bitmask Catalog Representation