Re: GSoC proposal - "make an unlogged table logged"

On Wed, Mar 5, 2014 at 7:42 PM, Fabrízio de Royes Mello
<fabriziomello(at)gmail(dot)com> wrote:
> On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello
> <fabriziomello(at)gmail(dot)com> wrote:
>> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
>> wrote:
>> >
>> > On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
>> > > On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund <andres(at)2ndquadrant(dot)com>
>> > > wrote:
>> > > > On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
>> > > > Can't that be solved by just creating the permanent relation in a
>> > > > new
>> > > > relfilenode? That's equivalent to a rewrite, yes, but we need to do
>> > > > that
>> > > > for anything but wal_level=minimal anyway.
>> > >
>> > > Yes, that would work. I've tended to view optimizing away the
>> > > relfilenode copy as an indispensable part of this work, but that might
>> > > be wrongheaded. It would certainly be a lot easier to make this
>> > > happen if we didn't insist on that.
>> >
>> > I think it'd already much better than today's situation, and it's a
>> > required codepath for wal_level > logical anyway. So even if somebody
>> > wants to make this work without the full copy for minimal, it'd still be
>> > a required codepath. So I am perfectly ok with a patch just adding that.
>> >
>>
>> Then is this a good idea for a GSoC project ?
>>
>> I don't know very well this internals, but I am willing to learn and I
>> think the GSoC is a good opportunity.
>>
>> Any of you are willing to mentoring this project?
>>
>
> I written the proposal to this feature, so I would like to know if someone
> can review.

I think this isn't a good design. Per the discussion between Andres
and I, I think that I think you should do is make ALTER TABLE .. SET
LOGGED work just like VACUUM FULL, with the exception that it will set
a different relpersistence for the new relfilenode. If you do it that
way, this will be less efficient, but much simpler, and you might
actually finish it in one summer.

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