| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
| Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [WIP] In-place upgrade |
| Date: | 2008-11-05 20:44:36 |
| Message-ID: | 2549.1225917876@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Martijn van Oosterhout napsal(a):
>> Is this really such a big deal? You do the null-update on the last
>> tuple of the page and then you do have enough room. So Phase one moves
>> a few tuples to make room. Phase 2 actually converts the pages inplace.
> Problem is how to move tuple from page to another and keep indexes in
> sync. One solution is to perform some think like "update" operation on
> the tuple. But you need exclusive lock on the page and pin counter
> have to be zero. And question is where it is safe operation.
Hmm. Well, it may be a nasty problem but you have to find a solution.
We're not going to guarantee that no update ever expands the data ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2008-11-05 20:45:24 | Re: A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD |
| Previous Message | Tom Lane | 2008-11-05 20:41:50 | Re: Toast bug in CVS HEAD |