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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Thom Brown <thom(at)linux(dot)com>, Christoph Berg <cb(at)df7cb(dot)de>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Date: 2014-08-22 20:54:38
Message-ID: 7883.1408740878@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

Maybe I misunderstood something, but I had the impression that this was
handled by assigning a new relfilenode (and hence copying all the data).
So the buffers with one marking would be disjoint from the ones with the
other marking.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-08-22 20:57:04 Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Previous Message Alvaro Herrera 2014-08-22 20:23:31 Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED