On Fri, Jun 24, 2016 at 4:33 AM, Andres Freund <and...@anarazel.de> wrote: > On 2016-06-23 18:59:57 -0400, Alvaro Herrera wrote: >> Andres Freund wrote: >> >> > I'm looking into three approaches right now: >> > >> > 3) Use WAL logging for the already_marked = true case. >> >> >> > 3) This approach so far seems the best. It's possible to reuse the >> > xl_heap_lock record (in an afaics backwards compatible manner), and in >> > most cases the overhead isn't that large. It's of course annoying to >> > emit more WAL, but it's not that big an overhead compared to extending a >> > file, or to toasting. It's also by far the simplest fix. >>
+1 for proceeding with Approach-3. >> I suppose it's fine if we crash midway from emitting this wal record and >> the actual heap_update one, since the xmax will appear to come from an >> aborted xid, right? > > Yea, that should be fine. > > >> I agree that the overhead is probably negligible, considering that this >> only happens when toast is invoked. It's probably not as great when the >> new tuple goes to another page, though. > > I think it has to happen in both cases unfortunately. We could try to > add some optimizations (e.g. only release lock & WAL log if the target > page, via fsm, is before the current one), but I don't really want to go > there in the back branches. > You are right, I think we can try such an optimization in Head and that too if we see a performance hit with adding this new WAL in heap_update. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
