Hello, I return to this before my things:) Though I haven't played with the patch yet..
At Fri, 29 Jul 2016 16:54:42 +0900, Michael Paquier <michael.paqu...@gmail.com> wrote in <CAB7nPqR+3JjS=JB3R=axxkxcyeb-q77u-erw7_ukajctwnt...@mail.gmail.com> > > Well, not that soon at the end, but I am back on that... I have not > > completely reviewed all the code yet, and the case of index relation > > referring to a relation optimized with truncate is still broken, but > > for now here is a rebased patch if people are interested. I am going > > to get as well a TAP tests out of my pocket to ease testing. > > The patch I sent yesterday was based on an incorrect version. Attached > is a slightly-modified version of the last one I found here > (https://www.postgresql.org/message-id/56b342f5.1050...@iki.fi), which > is rebased on HEAD at ed0b228. I have also converted the test case > script of upthread into a TAP test in src/test/recovery that covers 3 > cases and I included that in the patch: > 1) CREATE + INSERT + COPY => crash > 2) CREATE + trigger + COPY => crash > 3) CREATE + TRUNCATE + COPY => incorrect number of rows. > The first two tests make the system crash, the third one reports an > incorrect number of rows. At the first glance, managing sync_above and truncate_to is workable for these cases, but seems too complicated for the problem to be resolved. This provides smgr with a capability to manage pending page synchs. But the postpone-page-syncs-or-not issue rather seems to be a matter of the users of that, who are responsible for WAL issueing. Anyway heap_resgister_sync doesn't use any secret of smgr. So I think this approach binds smgr with Relation too tightly. By this patch, many RelationNeedsWALs, which just accesses local struct, are replaced with HeapNeedsWAL, which eventually accesses a hash added by this patch. Especially in log_heap_update, it is called for every update of single tuple (on a relation that needs WAL). Though I don't know how it actually impacts the perfomance, it seems to me that we can live with truncated_to and sync_above in RelationData and BufferNeedsWAL(rel, buf) instead of HeapNeedsWAL(rel, buf). Anyway up to one entry for one relation seems to exist at once in the hash. What do you think? regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
