Peter Eisentraut píše v čt 12. 02. 2009 v 15:30 +0200:
I am not aware of any server changes needed for 8.3-8.4 migration.
OK, Zdenek, any concerns, or can we consider this chapter closed?
I think, that it is closed now. Space reservation will be backported if
we need it for 8.4-8.5. And
On Thursday 12 February 2009 05:15:02 Bruce Momjian wrote:
I am working on pg_migrator TODO items. My current list is:
[long]
Can we clarify now that this is not going to ship with the PostgreSQL 8.4
tarball?
I am not aware of any server changes needed for 8.3-8.4 migration.
OK, Zdenek, any
Peter Eisentraut wrote:
On Thursday 12 February 2009 05:15:02 Bruce Momjian wrote:
I am working on pg_migrator TODO items. My current list is:
[long]
Can we clarify now that this is not going to ship with the PostgreSQL 8.4
tarball?
That is not really my decision, but I am not going to
Peter Eisentraut wrote:
Bruce Momjian wrote:
Now that pg_migrator is BSD licensed, and already in C, I am going to
spend my time trying to improve pg_migrator for 8.4:
http://pgfoundry.org/projects/pg-migrator/
What is the plan now? Get pg_upgrade working, get pg_migrator
Bruce Momjian wrote:
Now that pg_migrator is BSD licensed, and already in C, I am going to
spend my time trying to improve pg_migrator for 8.4:
http://pgfoundry.org/projects/pg-migrator/
What is the plan now? Get pg_upgrade working, get pg_migrator working,
ship pg_migrator in core
Zdenek Kotala wrote:
The current project is not in good shape. Feature freeze is coming and
nothing is committed. Currently there are three patches in the game:
1) Space reservation
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
On Thursday 29 January 2009 01:05:07 Tom Lane wrote:
The appeal of the pg_dump approach is that it will automatically handle
everything that there exists a plain-SQL representation for, which is to
say darn near everything. We will need special purpose code to deal
with the dropped-column and
Hm the previous proposal was to add syntax to create table to create
placeholder columns of specified width.
On the one hand the special syntax is less kludgy but on the other
hand keeping all the compatibility code in pg_dump is attractive. Net
I think prefer your solution.
I don't
Bruce Momjian píše v st 28. 01. 2009 v 23:19 -0500:
I am stumped as well. In the 12 years I have been involved, there are
perhaps five issues that the original pg_upgrade written in 1998 didn't
handle, and mostly handles now. Considering the number of catalog
changes since 1998, the ratio
Tom Lane píše v st 28. 01. 2009 v 18:05 -0500:
Robert Haas robertmh...@gmail.com writes:
I really like this idea, assuming I understand it. Basically, I think
you're proposing that we move the old system catalogs out of the way,
bootstrap a new catalog, and then using SQL (running inside
Heikki Linnakangas píše v st 28. 01. 2009 v 09:24 +0200:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
That implies a fairly robust and configurable system for adding to and
rewriting system catalogs, which today we haven't got.
And we won't ever have, because it's
* Zdenek Kotala (zdenek.kot...@sun.com) wrote:
And very important thing is that you need old version of postgreSQL
installed, which is something what packagers does not want. Look on
Oracle how does it.
Just as a counter-point, Debian handles multiple concurrently installed
versions of
Zdenek Kotala zdenek.kot...@sun.com writes:
Heikki Linnakangas pÃÅ¡e v st 28. 01. 2009 v 09:24 +0200:
Right, the dump+initdb+reload approach works quite well in both
pg_upgrade and pg-migrator. I believe the biggest issue with that ATM is
supporting dropped columns, and maybe there's
Stephen Frost sfr...@snowman.net writes:
* Zdenek Kotala (zdenek.kot...@sun.com) wrote:
And very important thing is that you need old version of postgreSQL
installed, which is something what packagers does not want. Look on
Oracle how does it.
Just as a counter-point, Debian handles multiple
On Wed, Jan 28, 2009 at 10:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Zdenek Kotala zdenek.kot...@sun.com writes:
Heikki Linnakangas píše v st 28. 01. 2009 v 09:24 +0200:
Right, the dump+initdb+reload approach works quite well in both
pg_upgrade and pg-migrator. I believe the biggest issue with
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 28, 2009 at 10:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Sure, but the other way is just a complete non-starter.
Well, the goal of coding is to make such things easier. Already the
solution you're advocating has one huge wart: the need to
Tom Lane píše v st 28. 01. 2009 v 14:06 -0500:
Trying to do catalog upgrade
in-place is going to be a complete mess. I'd be interested to know,
for example, how you imagine rearranging the contents of pg_class would
work. You don't get to modify pg_class if you can't even find it, which
On Wed, Jan 28, 2009 at 5:00 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Tom Lane píše v st 28. 01. 2009 v 14:06 -0500:
Trying to do catalog upgrade
in-place is going to be a complete mess. I'd be interested to know,
for example, how you imagine rearranging the contents of pg_class would
Robert Haas robertmh...@gmail.com writes:
I really like this idea, assuming I understand it. Basically, I think
you're proposing that we move the old system catalogs out of the way,
bootstrap a new catalog, and then using SQL (running inside a
standalone backend?) to migrate data from the
On Wed, Jan 28, 2009 at 6:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, what it really means is that all the special-purpose conversion
code is in SQL instead of C. Which is sort of good as long as whatever
transformation you have in mind can be done easily in SQL. (Good luck
if you need
Tom Lane wrote:
The appeal of the pg_dump approach is that it will automatically handle
everything that there exists a plain-SQL representation for, which is to
say darn near everything. We will need special purpose code to deal
with the dropped-column and TOAST-oid issues, but that can
The current project is not in good shape. Feature freeze is coming and
nothing is committed. Currently there are three patches in the game:
1) Space reservation
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
http://archives.postgresql.org/pgsql-hackers/2009-01/msg02031.php
Zdenek Kotala wrote:
The current project is not in good shape. Feature freeze is coming and
nothing is committed. Currently there are three patches in the game:
[...]
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for
Andrew Dunstan wrote:
Zdenek Kotala wrote:
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for catalog conversion. It works for
8.3-8.4 upgrade. It will be useful while we will not have better
solution. Disadvantage is that it is
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Zdenek Kotala wrote:
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for catalog conversion. It works for
8.3-8.4 upgrade. It will be useful while we will not have better
On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it's fairly easy to install Perl on Windows actually. It
doesn't sound too onerous a requirement if you want in-place upgrade;
actually it looks a very reasonable one.
There are installers for it, but
On Tue, Jan 27, 2009 at 11:39:50AM -0300, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Zdenek Kotala wrote:
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for catalog conversion. It works for
On Tue, Jan 27, 2009 at 8:44 AM, Zdenek Kotala zdenek.kot...@sun.com wrote:
The current project is not in good shape. Feature freeze is coming and
nothing is committed. Currently there are three patches in the game:
Correction: feature freeze is long past.
1) Space reservation
Zdenek Kotala wrote:
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for catalog conversion. It works for
8.3-8.4 upgrade.
What's the reason this script uses a postmaster? It seems it would be
easier to control if you used a
On 1/27/09, Zdenek Kotala zdenek.kot...@sun.com wrote:
This patch is mandatory for page online conversion and MUST TO be part
of postgreSQL 8.4. if not ... then we will be at the beginning next
year.
Just to clarify, does that mean that your patch has to be in for there
to be any chance of
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Zdenek Kotala wrote:
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for catalog conversion. It works for
8.3-8.4 upgrade. It will be useful while we will not have better
Dave Page wrote:
On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it's fairly easy to install Perl on Windows actually. It
doesn't sound too onerous a requirement if you want in-place upgrade;
actually it looks a very reasonable one.
There are
Dave Page dp...@pgadmin.org writes:
On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it's fairly easy to install Perl on Windows actually. It
doesn't sound too onerous a requirement if you want in-place upgrade;
actually it looks a very reasonable
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Zdenek Kotala wrote:
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for catalog conversion. It works for
8.3-8.4 upgrade. It will be useful while we
On Tue, Jan 27, 2009 at 2:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Dave Page wrote:
On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it's fairly easy to install Perl on Windows actually. It
doesn't sound too onerous a requirement if
* Magnus Hagander (mag...@hagander.net) wrote:
Either way, there's no point to discuss that in detail until there
actually is a working implementation out there... perl will do fine
until then. Once we have that, we can discuss if doing it in C will be
worthwhile, or if we're just going to
* Robert Haas (robertmh...@gmail.com) wrote:
[pg_upgrade...]
Why is the deadline different than anything else?
err, isn't it because it'd be kind of difficult to do an upgrade script
with large catalog-changing patches outstanding..? I thought some
leeway was given for pg_upgrade specifically
On Tue, Jan 27, 2009 at 10:08 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
[pg_upgrade...]
Why is the deadline different than anything else?
err, isn't it because it'd be kind of difficult to do an upgrade script
with large catalog-changing patches
I think it's fairly easy to install Perl on Windows actually. It
doesn't sound too onerous a requirement if you want in-place upgrade;
actually it looks a very reasonable one.
Much more reasonable than Korn shell in any case (or any shell for that
matter; I think anything is going to be
Hi
I have had a very brief look at this. Translation to perl doesn't look
difficult. I'll see what I can do during the next week or so.
Perhaps I can lend you a hand if you need help with this.
--
Med venlig hilsen
Kaare Rasmussen, Jasonic
Jasonic Telefon: +45 3816 2582
Harald Armin Massa wrote:
I think it's fairly easy to install Perl on Windows actually. It
doesn't sound too onerous a requirement if you want in-place upgrade;
actually it looks a very reasonable one.
Much more reasonable than Korn shell in any case (or any shell for that
matter; I think
Alvaro Herrera píše v út 27. 01. 2009 v 11:47 -0300:
Zdenek Kotala wrote:
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for catalog conversion. It works for
8.3-8.4 upgrade.
What's the reason this script uses a
On Tue, 2009-01-27 at 09:48 -0500, Andrew Dunstan wrote:
We don't require perl for any other feature, do we? Seems like a
pretty onerous requireemnt for Windows in particular. We do use perl
in the build scripts, but that's only required if you want to compile
from source.
Well,
Joshua D. Drake wrote:
On Tue, 2009-01-27 at 09:48 -0500, Andrew Dunstan wrote:
We don't require perl for any other feature, do we? Seems like a
pretty onerous requireemnt for Windows in particular. We do use perl
in the build scripts, but that's only required if you want to compile
On Tue, 2009-01-27 at 10:56 -0500, Andrew Dunstan wrote:
That's what my brief examination of the script was about - looking to
see if it could be translated portably. I think it very probably can. I
suspect it won't need any modules at all. I suspect any
Accidental ctrl-enter?
O.k.
On Tue, Jan 27, 2009 at 04:23:18PM +0100, Harald Armin Massa wrote:
I think it's fairly easy to install Perl on Windows actually. It
doesn't sound too onerous a requirement if you want in-place upgrade;
actually it looks a very reasonable one.
Much more reasonable than Korn shell in any
Merlin Moncure píše v út 27. 01. 2009 v 09:47 -0500:
On 1/27/09, Zdenek Kotala zdenek.kot...@sun.com wrote:
This patch is mandatory for page online conversion and MUST TO be part
of postgreSQL 8.4. if not ... then we will be at the beginning next
year.
Just to clarify, does that mean
Robert Haas píše v út 27. 01. 2009 v 09:45 -0500:
1) Space reservation
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
http://archives.postgresql.org/pgsql-hackers/2009-01/msg02031.php
This patch is mandatory for page online conversion and MUST TO be part
of
Magnus Hagander píše v út 27. 01. 2009 v 15:54 +0100:
I have a hard time thinking that we'll have wasted a lot of time on
first doing a perl implementation if we have to rewrite it in C later.
The other way around would be a waste though. The amount of time spent
on the perl implementation
Dave Page píše v út 27. 01. 2009 v 14:56 +:
On Tue, Jan 27, 2009 at 2:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Dave Page wrote:
On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it's fairly easy to install Perl on Windows
Zdenek Kotala wrote:
Robert Haas píše v út 27. 01. 2009 v 09:45 -0500:
1) Space reservation
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
http://archives.postgresql.org/pgsql-hackers/2009-01/msg02031.php
This patch is mandatory for page online conversion and MUST TO be
Zdenek Kotala wrote:
Magnus Hagander píše v út 27. 01. 2009 v 15:54 +0100:
I have a hard time thinking that we'll have wasted a lot of time on
first doing a perl implementation if we have to rewrite it in C later.
The other way around would be a waste though. The amount of time spent
on the
Heikki Linnakangas píše v út 27. 01. 2009 v 21:07 +0200:
Zdenek Kotala wrote:
Robert Haas píše v út 27. 01. 2009 v 09:45 -0500:
1) Space reservation
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
http://archives.postgresql.org/pgsql-hackers/2009-01/msg02031.php
Zdenek Kotala zdenek.kot...@sun.com writes:
Merlin Moncure pÃÅ¡e v út 27. 01. 2009 v 09:47 -0500:
Just to clarify, does that mean that your patch has to be in for there
to be any chance of in-place upgrade 8.4-8.5?
Ok, There two patch in the queue for 8.5 which will bump page layout
On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Dave Page píše v út 27. 01. 2009 v 14:56 +:
I'd rather it was written in an appropriate language before feature
freeze, not in a language that makes it easier for the author but a
shade harder for thousands of
Zdenek Kotala wrote:
Set general value for heap or btree is possible but not optimal. For
example If you have 5TB table and page layout changes do not affected
this table but some small table needs perform a cleanup then 5TB will be
processed in general approach, but in optimal variant it will
Heikki Linnakangas píše v út 27. 01. 2009 v 21:13 +0200:
Zdenek Kotala wrote:
Magnus Hagander píše v út 27. 01. 2009 v 15:54 +0100:
I have a hard time thinking that we'll have wasted a lot of time on
first doing a perl implementation if we have to rewrite it in C later.
The other way
Tom Lane píše v út 27. 01. 2009 v 14:31 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
Merlin Moncure píše v út 27. 01. 2009 v 09:47 -0500:
Just to clarify, does that mean that your patch has to be in for there
to be any chance of in-place upgrade 8.4-8.5?
Ok, There two patch in
Heikki Linnakangas píše v út 27. 01. 2009 v 21:37 +0200:
Zdenek Kotala wrote:
Set general value for heap or btree is possible but not optimal. For
example If you have 5TB table and page layout changes do not affected
this table but some small table needs perform a cleanup then 5TB will be
On Tue, 2009-01-27 at 20:46 +0100, Zdenek Kotala wrote:
And last I think license is not BSD, I don't know how big problem it is.
Uhh.. that kills it. We only accept BSD.
Joshua D. Drake
Zdenek
--
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
Consulting, Development,
Joshua D. Drake wrote:
On Tue, 2009-01-27 at 20:46 +0100, Zdenek Kotala wrote:
And last I think license is not BSD, I don't know how big problem it is.
Uhh.. that kills it. We only accept BSD.
Actually, that was just fixed. Once somebody raised the issue, EDB
changed the license (there
Joshua D. Drake wrote:
On Tue, 2009-01-27 at 20:46 +0100, Zdenek Kotala wrote:
And last I think license is not BSD, I don't know how big problem it is.
Uhh.. that kills it. We only accept BSD.
Actually, it has been relicensed to BSD license, after a short
discussion started by Bruce
On Tue, 2009-01-27 at 22:12 +0200, Heikki Linnakangas wrote:
Joshua D. Drake wrote:
On Tue, 2009-01-27 at 20:46 +0100, Zdenek Kotala wrote:
And last I think license is not BSD, I don't know how big problem it is.
Uhh.. that kills it. We only accept BSD.
Actually, it has been
Dave Page píše v út 27. 01. 2009 v 19:36 +:
On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Dave Page píše v út 27. 01. 2009 v 14:56 +:
I'd rather it was written in an appropriate language before feature
freeze, not in a language that makes it easier
On Tue, Jan 27, 2009 at 8:31 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Dave Page píše v út 27. 01. 2009 v 19:36 +:
On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Dave Page píše v út 27. 01. 2009 v 14:56 +:
I'd rather it was written in an
Dave Page píše v út 27. 01. 2009 v 20:36 +:
On Tue, Jan 27, 2009 at 8:31 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Neither of which are the correct place to submit work for inclusion in
PostgreSQL.
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00990.php
I sent it
On Tuesday 27 January 2009 21:36:01 Dave Page wrote:
If it's been around for a year, why hasn't it been
submitted long ago so we could have rewritten and reviewed etc. in
plenty of time?
It's in the commit fest listing, and the discussion about which programming
language to port it to
On Tue, Jan 27, 2009 at 8:52 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01051.php
But you can read there that it is korn shell script and there is link to
it.
OK, yes that does mention it. It's not exactly clear that it's
something
On Tuesday 27 January 2009 16:52:15 Tom Lane wrote:
Indeed. We might put up with a perl script for awhile for the sake of
development expediency, but the long-term expectation would have to be
that someone would rewrite it in C. Given that, I wonder whether
there's much point in a rewrite
On Tuesday 27 January 2009 16:54:02 Magnus Hagander wrote:
Either way, there's no point to discuss that in detail until there
actually is a working implementation out there... perl will do fine
until then
There is a working implementation out there. It is -- you guessed it --
sitting in the
On Tue, Jan 27, 2009 at 8:54 PM, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 27 January 2009 21:36:01 Dave Page wrote:
If it's been around for a year, why hasn't it been
submitted long ago so we could have rewritten and reviewed etc. in
plenty of time?
It's in the commit fest listing,
On Tuesday 27 January 2009 17:27:32 Kaare Rasmussen wrote:
Hi
I have had a very brief look at this. Translation to perl doesn't look
difficult. I'll see what I can do during the next week or so.
Perhaps I can lend you a hand if you need help with this.
Not to stop you are anything, but in
On Tue, 27 Jan 2009, Peter Eisentraut wrote:
On Tuesday 27 January 2009 21:36:01 Dave Page wrote:
If it's been around for a year, why hasn't it been
submitted long ago so we could have rewritten and reviewed etc. in
plenty of time?
It's in the commit fest listing, and the discussion about
On Tuesday 27 January 2009 23:02:30 Dave Page wrote:
On Tue, Jan 27, 2009 at 8:54 PM, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 27 January 2009 21:36:01 Dave Page wrote:
If it's been around for a year, why hasn't it been
submitted long ago so we could have rewritten and reviewed
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 27 January 2009 16:52:15 Tom Lane wrote:
Indeed. We might put up with a perl script for awhile for the sake of
development expediency, but the long-term expectation would have to be
that someone would rewrite it in C. Given that, I wonder
I thought we pretty much had agreement that space reservation was not
a good solution to anything, although I admit I'm not quite clear on
what alternative was being proposed.
Maybe I miss something, but space reservation was selected as a best
way. Please, Could you point me related mailing
for getting 8.4-8.5 upgrade into place. You should first work on an
update process that supports catalog changes, and get that committed.
Once that's in place you'll have enough political capital to prevent
changes in user data layout, and then we'd start to think about schemes
like space
Robert Haas robertmh...@gmail.com writes:
That implies a fairly robust and configurable system for adding to and
rewriting system catalogs, which today we haven't got.
And we won't ever have, because it's unnecessary and would be impossibly
complex. We know how to do the catalog update:
On Tue, 27 Jan 2009, Robert Haas wrote:
That implies a fairly robust and configurable system for adding to and
rewriting system catalogs, which today we haven't got.
Right, and designing such a system requires a fairly deep analysis of the
catalog changes that have historically shown up, to
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
That implies a fairly robust and configurable system for adding to and
rewriting system catalogs, which today we haven't got.
And we won't ever have, because it's unnecessary and would be impossibly
complex. We know how to do the
Zdenek Kotala wrote:
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add
other
topic which should be finished for 8.4.
Convert on read has
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
snip
1) Data does not fit on the new page. It will be solve by pre-upgrade check
which reserve space on each page, before upgrade.
Rather than specifying free space as an amount, I was thinking of
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add other
topic which should be finished for 8.4.
Convert on read has been selected as a good way,
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add other
topic which should be finished for 8.4.
Convert on read has been selected as a good way, because it is not invasive and
does not limit fresh
Zdenek Kotala wrote:
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add other
topic which should be finished for 8.4.
Convert on read has been selected as a good way, because it is not invasive
Bruce Momjian [EMAIL PROTECTED] writes:
1) Data does not fit on the new page. It will be solve by pre-upgrade check
which reserve space on each page, before upgrade.
Rather than specifying free space as an amount, I was thinking of having
a boolean like 'ready_for_upgrade' and the system
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
1) Data does not fit on the new page. It will be solve by pre-upgrade
check
which reserve space on each page, before upgrade.
Rather than specifying free space as an amount, I was thinking of having
a boolean like
87 matches
Mail list logo
