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.
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 goi
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, an
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_migrat
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 o
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
> http://archives.postgresql.org/pgsql-h
Tom Lane píše v st 28. 01. 2009 v 18:05 -0500:
> Robert Haas 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
> > standalon
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 rat
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 thin
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
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 pr
On Wed, Jan 28, 2009 at 6:05 PM, Tom Lane 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 to control the O
Robert Haas 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 old catalog to the n
On Wed, Jan 28, 2009 at 5:00 PM, Zdenek Kotala 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
>> work. You do
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
Robert Haas writes:
> On Wed, Jan 28, 2009 at 10:52 AM, Tom Lane 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 represent
> dropped columns in pg_
On Wed, Jan 28, 2009 at 10:52 AM, Tom Lane wrote:
> Zdenek Kotala 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 dro
Stephen Frost 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 concurrent
Zdenek Kotala 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 something else, but i
* 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 Postg
Heikki Linnakangas píše v st 28. 01. 2009 v 09:24 +0200:
> Tom Lane wrote:
> > Robert Haas 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
Tom Lane wrote:
Robert Haas 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: basically,
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 m
Robert Haas 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: basically, dump, initdb,
r
> 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 spa
>> 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
Peter Eisentraut 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 whether
>>
On Tuesday 27 January 2009 23:02:30 Dave Page wrote:
> On Tue, Jan 27, 2009 at 8:54 PM, 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
>
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 whi
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,
On Tue, Jan 27, 2009 at 8:54 PM, 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 th
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 th
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 Tue, Jan 27, 2009 at 8:52 PM, Zdenek Kotala 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 you wanted to inc
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 happe
Dave Page píše v út 27. 01. 2009 v 20:36 +:
> On Tue, Jan 27, 2009 at 8:31 PM, Zdenek Kotala 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 in
On Tue, Jan 27, 2009 at 8:31 PM, Zdenek Kotala wrote:
>
> Dave Page píše v út 27. 01. 2009 v 19:36 +:
>> On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala 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
>>
Dave Page píše v út 27. 01. 2009 v 19:36 +:
> On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala 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 auth
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 ha
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 within
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 ha
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, Developmen
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 w
Tom Lane píše v út 27. 01. 2009 v 14:31 -0500:
> Zdenek Kotala 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 f
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.
> >> T
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 b
On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala 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 users three month
Zdenek Kotala 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
> version. Then we wil
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/m
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 per
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 part
Dave Page píše v út 27. 01. 2009 v 14:56 +:
> On Tue, Jan 27, 2009 at 2:49 PM, Alvaro Herrera
> wrote:
> > Dave Page wrote:
> >> On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
> >> wrote:
> >>
> >> > I think it's fairly easy to install Perl on Windows actually. It
> >> > doesn't sound too
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 implementa
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
Merlin Moncure píše v út 27. 01. 2009 v 09:47 -0500:
> On 1/27/09, Zdenek Kotala 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 pa
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 she
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.
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
from
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.
>
>
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 sc
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 any
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
No
> 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 b
On Tue, Jan 27, 2009 at 10:08 AM, Stephen Frost 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 outstanding
* 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 d
* 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
On Tue, Jan 27, 2009 at 2:49 PM, Alvaro Herrera
wrote:
> Dave Page wrote:
>> On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
>> 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
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.
Dave Page writes:
> On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
> 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, bu
Dave Page wrote:
> On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
> 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
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
solutio
On 1/27/09, Zdenek Kotala 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 in-place upgrade 8.
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 u
On Tue, Jan 27, 2009 at 8:44 AM, 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:
Correction: feature freeze is long past.
> 1) Space reservation
> http://archives.postgresql.org/p
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 conver
On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
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 given that we made a poin
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 h
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
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 ca
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
This
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
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 havin
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.
> >>
> >> C
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, becaus
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 b
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 s
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 invasi
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 d
87 matches
Mail list logo
