On Wed, Jul 16, 2014 at 7:26 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2014-07-16 20:53:06 +0200, Andres Freund wrote: > > On 2014-07-16 20:25:42 +0200, Andres Freund wrote: > > > Hi, > > > > > > I quickly looked at this patch and I think there's major missing pieces > > > around buffer management and wal logging. > > > > > > a) Currently buffers that are in memory marked as > > > permanent/non-permanent aren't forced out to disk/pruned from cache, > > > not even when they're dirty. > > > b) When converting from a unlogged to a logged table the relation needs > > > to be fsynced. > > > c) Currently a unlogged table changed into a logged one will be > > > corrupted on a standby because its contents won't ever be WAL logged. > > > > Forget that, didn't notice that you're setting tab->rewrite = true. > > So, while that danger luckily isn't there I think there's something > similar. Consider: > > CREATE TABLE blub(...); > INSERT INTO blub ...; > > BEGIN; > ALTER TABLE blub SET UNLOGGED; > ROLLBACK; > > The rewrite will read in the 'old' contents - but because it's done > after the pg_class.relpersistence is changed they'll all not be marked > as BM_PERMANENT in memory. Then the ALTER TABLE is rolled back, > including the relpersistence setting. Which will unfortunately leave > pages with the wrong persistency setting in memory, right? >
That means should I "FlushRelationBuffers(rel)" before change the relpersistence? Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello