On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>
> > 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.


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

Reply via email to