On Thu, Apr 23, 2015 at 12:55 AM, Andres Freund <and...@anarazel.de> wrote: > I think you misread my statement: I'm saying we don't need the new > argument anymore, even if we still do the super-deletion in > heap_delete(). Now that the speculative insertion will not be visible > (as in seen on a tuple they could delete) to other backends we can just > do the super deletion if we see that the tuple is a promise one.
I disagree. I think it's appropriate that the one and only "super" heap_delete() caller make a point of indicating that that's what it's doing. The cost is only that the two other such callers must say that they're not doing it. Super deletion is a special thing, that logical decoding knows all about for example, and I think it's appropriate that callers ask explicitly. >> > * breinbaas on IRC just mentioned that it'd be nice to have upsert as a >> > link in the insert. Given that that's the pervasive term that doesn't >> > seem absurd. >> >> Not sure what you mean. Where would the link appear? > > The index, i.e. it'd just be another indexterm. It seems good to give > people a link. Oh, okay. Sure. Done on Github. >> * We need to figure out the tuple lock strength details. I think this >> is doable, but it is the greatest challenge to committing ON CONFLICT >> UPDATE at this point. Andres feels that we should require no greater >> lock strength than an equivalent UPDATE. I suggest we get to this >> after committing the IGNORE variant. We probably need to discuss this >> some more. > > I want to see a clear way forward before we commit parts. It doesn't > have to be completely iron-clad, but the way forward should be pretty > clear. What's the problem you're seeing right now making this work? A > couple days on jabber you seemed to see a way doing this? I was really just identifying it as the biggest problem the patch now faces, and I want to face those issues down ASAP. Of course, that's good, because as you say it is a small problem in an absolute sense. The second most significant open item is rebasing on top of the recent RLS changes, IMV. I can see yourself and Heikki continuing to change small stylistic things, which I expect to continue for a little while. That's fine, but naturally I want to be aggressive about closing off these open issues that are not just general clean-up, but have some small level of risk of becoming more significant blockers. > The reason I think this has to use the appropriate lock level is that > it'll otherwise re-introduce the deadlocks that fk locks resolved. Given > how much pain we endured to get fk locks, that seems like a bad deal. Right. -- 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
