| From: | Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: Freeze avoidance of very large table. |
| Date: | 2015-04-21 15:15:53 |
| Message-ID: | CAD21AoDi8ws01hTP4Bn9ohF5__ej5T11RHx6G-Hmy9mZY_Jf5w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 22, 2015 at 12:02 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-04-21 23:59:45 +0900, Sawada Masahiko wrote:
>> The page as frozen could have the dead tuple for now, but I think to change
>> to that the frozen page guarantees that page is all frozen *and* all
>> visible.
>
> It shouldn't. That'd potentially cause corruption after a wraparound. A
> tuple's visibility might change due to that.
The page as frozen could have some dead tuples, right?
I think we should to clear a bit of FrozenMap (and flag of page
header) on delete operation, and a bit is set only by vacuum.
So accordingly, the page as frozen guarantees that all frozen and all visible?
Regards,
-------
Sawada Masahiko
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2015-04-21 15:20:42 | Re: Replication identifiers, take 4 |
| Previous Message | Stephen Frost | 2015-04-21 15:15:11 | preprocess_targetlist and inheiritance |