| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, daveg(at)sonic(dot)net, Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |
| Date: | 2009-09-04 21:01:25 |
| Message-ID: | 21715.1252098085@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Well at bootstrap time I guess noone is able to disturb the system by
> placing a concurrent CLUSTER pg_class; call. Once started, do those rels
> still need to have a special behavior?
It doesn't matter, if you fail to get past bootstrap because you
couldn't find pg_class. The existing design for this is absolutely
dependent on the fact that pg_class has a fixed relfilenode = fixed
physical file name. MVCC has nothing to do with it.
See my followon message for a sketch of a possible solution. Basically
it's pushing the fixed file name over to another place ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2009-09-04 21:27:19 | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |
| Previous Message | Alvaro Herrera | 2009-09-04 21:00:53 | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |