Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED

On Wed, Jul 16, 2014 at 7:26 PM, Andres Freund <andres(at)2ndquadrant(dot)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