| From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Prototype: In-place upgrade v02 |
| Date: | 2008-09-08 13:01:00 |
| Message-ID: | 48C5220C.2000909@sun.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:
>> Heikki Linnakangas napsal(a):
>>> Relation forks didn't change anything inside relation files, so no
>>> scanning of relations is required because of that. Neither will the
>>> FSM rewrite. Not sure about DSM yet.
>>
>> Does it mean, that if you "inject" old data file after catalog
>> upgrade, then FSM will works without any problem?
>
> Yes. You'll need to construct an FSM, but it doesn't necessarily need to
> reflect the reality. You could just fill it with zeros, meaning that
> there's no free space anywhere, and let the next vacuum fill it with
> real information. Or you could read the old pg_fsm.cache file and fill
> the new FSM accordingly.
I think zeroed FSM is good, because new items should not be added on to old page.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2008-09-08 13:05:06 | Re: reducing statistics write overhead |
| Previous Message | Zdenek Kotala | 2008-09-08 12:57:20 | Re: Prototype: In-place upgrade v02 |