Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Date
Msg-id CA+TgmobZd6trMN=9QtqvN6ZEVzdqYn8OKEFiqjZr7zNMnH4kFg@mail.gmail.com
Whole thread Raw
In response to Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
List pgsql-hackers
On Fri, Aug 22, 2014 at 2:32 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Fabrízio de Royes Mello wrote:
>> Em sexta-feira, 22 de agosto de 2014, Alvaro Herrera <
>> alvherre@2ndquadrant.com> escreveu:
>>
>> > Fabrízio de Royes Mello wrote:
>> >
>> > > I forgot to mention... I did again a lot of tests using different
>> > > replication scenarios to make sure all is ok:
>> > > - slaves async
>> > > - slaves sync
>> > > - cascade slaves
>> >
>> > On v13 you mean?
>> >
>> Exactly!
>
> Great.  Pushed.  Thanks for the patch.

Hmm.  I confess to not having paid enough attention to this, but:

1. Loggedness is not a word.  I think that "persistence" or
"relpersistence" would be better.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCH] Incremental backup: add backup profile to base backup
Next
From: Robert Haas
Date:
Subject: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg