On Tue, Mar 3, 2015 at 12:05 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: >> My experimental branch works just fine (with a variant jjanes_upsert >> with subxact looping), until I need to restart an update after a >> "failed" heap_update() that still returned HeapTupleMayBeUpdated >> (having super deleted within an ExecUpdate() call). There is no good >> way to do that for ExecUpdate() that I can see, because an existing, >> visible row is affected (unlike with ExecInsert()). Even if it was >> possible, it would be hugely invasive to already very complicated code >> paths. > > Ah, so we can't easily use super-deletion to back out an UPDATE. I had not > considered that.
Yeah. When I got into considering making EvalPlanQualFetch() look at speculative tokens, it became abundantly clear that that code would never be committed, even if I could make it work. >> I continue to believe that the best way forward is to incrementally >> commit the work by committing ON CONFLICT IGNORE first. That way, >> speculative tokens will remain strictly the concern of UPSERTers or >> sessions doing INSERT ... ON CONFLICT IGNORE. > > > Ok, let's try that. Can you cut a patch that does just ON CONFLICT IGNORE, > please? Of course. I'll have that for your shortly. Thanks -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
