| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(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 09:10:36 |
| Message-ID: | 48C4EC0C.2090400@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> PS: I plan to review FSM this week.
Thanks!
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2008-09-08 09:13:27 | Re: Prototype: In-place upgrade v02 |
| Previous Message | ITAGAKI Takahiro | 2008-09-08 08:59:41 | Re: [Review] pgbench duration option |