On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > > 2. The patch seems to think that it can sometimes be safe to change > > the relpersistence of an existing relation. Unless you can be sure > > that no buffers can possibly be present in shared_buffers and nobody > > will use an existing relcache entry to read a new one in, it's not, > > because the buffers won't have the right BM_PERSISTENT marking. I'm > > very nervous about the fact that this patch seems not to have touched > > bufmgr.c, but maybe I'm missing something. > > Right. Andres pointed this out previously, and the patch was updated > consequently. The only remaining case in which we do that, again AFAIR, > is for indexes, just after the table has been rewritten and just before > the indexes are reindexed. There should be no buffer access of the old > indexes at that point, so there would be no buffer marked with the wrong > flag. Also, the table is locked access-exclusively (is that a word?), > so no other transaction could possibly be reading buffers for its > indexes. > > I pointed out, in the email just before pushing the patch, that perhaps > we should pass down the new relpersistence flag into finish_heap_swap, > and from there we could pass it down to reindex_index() which is where > it would be needed. I'm not sure it's worth the trouble, but I think we > can still ask Fabrizio to rework that part. > > Maybe it is me missing something. > > BTW why is it that index_build() checks the heap's relpersistence flag > rather than the index'? >
I can rework this part if it's a real concern. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog: http://fabriziomello.github.io >> Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello >> Github: http://github.com/fabriziomello
