On Fri, Mar 11, 2016 at 9:32 AM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > At Fri, 19 Feb 2016 22:27:00 +0900, Michael Paquier > <michael.paqu...@gmail.com> wrote in > <cab7npqsgfkuafqpe5t30jeea+v9yfmm4yjga3snkgy1rhzn...@mail.gmail.com> >> > Worth noting that this patch does not address the problem with index >> > relations when a TRUNCATE is used in the same transaction as its > > Focusing this issue, what we should do is somehow building empty > index just after a index truncation. The attached patch does the > following things to fix this. > > - make index_build use ambuildempty when the relation on which > the index will be built is apparently empty. That is, when the > relation has no block. > - add one parameter "persistent" to ambuildempty(). It behaves as > before if the parameter is false. If not, it creates an empty > index on MAIN_FORK and emits logs even if wal_level is minimal.
Hm. It seems to me that this patch is just a bandaid for the real problem which is that we should not TRUNCATE the underlying index relations when the TRUNCATE optimization is running. In short I would let the empty routines in AM code paths alone, and just continue using them for the generation of INIT_FORKNUM with unlogged relations. Your patch is not something backpatchable anyway I think. > The new parameter 'persistent' would be better be forknum because > it actually represents the persistency of the index to be > created. But I'm out of time now.. I actually have some users running with wal_level to minimal, even if I don't think they use this optimization, we had better fix even index relations at the same time as table relations.. I'll try to get some time once the patch review storm goes down a little, except if someone beats me to it first. -- Michael -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers