On Wed, Dec 2, 2009 at 3:48 PM, Tom Lane wrote:
> Greg Stark writes:
>> This whole discussion is based on assumptions which do not match my
>> recollection of the old discussion. I would suggest people go back and
>> read the emails but it's clear at least some people have so it seems
>> people g
Greg Stark writes:
> This whole discussion is based on assumptions which do not match my
> recollection of the old discussion. I would suggest people go back and
> read the emails but it's clear at least some people have so it seems
> people get different things out of those old emails. My recolle
On Wed, Dec 2, 2009 at 6:34 PM, Robert Haas wrote:
>> Also, your logic seems to presume that no backports are possible to the old
>> server.
>
> The problem on the table at the moment is that the proposed CRC
> feature will expand every page by a uniform amount - so in this case a
> fixed-space-pe
On Wed, Dec 2, 2009 at 2:27 PM, Greg Smith wrote:
> Robert Haas wrote:
>
> On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith wrote:
>
>
> There's no reason the associated catalog support had to ship with the old
> version. You can always modify the catalog after initdb, but before running
> the pre-upg
Robert Haas wrote:
On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith wrote:
There's no reason the associated catalog support had to ship with the old
version. You can always modify the catalog after initdb, but before running
the pre-upgrade utility. pg_migrator might make that change for you.
On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith wrote:
> Robert Haas wrote:
>>> Some additional catalog support was suggested to mark what the
>>> pre-upgrade
>>> utility had processed. I'm sure I could find the messages about again
>>> if I
>>> had to.
>> And that's a perfectly sensible solution, ex
Robert Haas wrote:
Some additional catalog support was suggested to mark what the pre-upgrade
utility had processed. I'm sure I could find the messages about again if I
had to.
And that's a perfectly sensible solution, except that adding a catalog
column to 8.4 at this point would force i
On Wed, Dec 2, 2009 at 1:08 PM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> The problem I'm referring to is that there is no guarantee that you
>> would be able predict how much space to reserve. In a case like CRCs,
>> it may be as simple as "4 bytes". But what if, say, we switch to a
>> diffe
Robert Haas wrote:
The problem I'm referring to is that there is no guarantee that you
would be able predict how much space to reserve. In a case like CRCs,
it may be as simple as "4 bytes". But what if, say, we switch to a
different compression algorithm for inline toast?
Upthread, you made a
On Wed, Dec 2, 2009 at 11:08 AM, Simon Riggs wrote:
> On Wed, 2009-12-02 at 10:48 -0500, Robert Haas wrote:
>> Well, that's sort of a circular argument. If you're going to reserve
>> space with a pre-upgrade utility, you're going to need to put the
>> pre-upgrade utility into the version you want
On Wed, 2009-12-02 at 10:48 -0500, Robert Haas wrote:
> Well, that's sort of a circular argument. If you're going to reserve
> space with a pre-upgrade utility, you're going to need to put the
> pre-upgrade utility into the version you want to upgrade FROM. If we
> wanted to be able to use a pre-
On Tue, Dec 1, 2009 at 11:45 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> >> The key issue, as I think Heikki identified at the time, is to figure
>> >> out how you're eventually going to get rid of the old pages. ?He
>> >> proposed running a pre-upgrade utility on each page to reserve the
>>
David Fetter wrote:
> > Right. There were two basic approaches to handling a patch that
> > would expand when upgraded to the new version --- either allow the
> > system to write the old format, or have a pre-upgrade script that
> > moved tuples so there was guaranteed enough free space in every p
On Tue, Dec 01, 2009 at 10:34:11PM -0500, Bruce Momjian wrote:
> Robert Haas wrote:
> > The key issue, as I think Heikki identified at the time, is to
> > figure out how you're eventually going to get rid of the old
> > pages. He proposed running a pre-upgrade utility on each page to
> > reserve t
Robert Haas wrote:
> >> The key issue, as I think Heikki identified at the time, is to figure
> >> out how you're eventually going to get rid of the old pages. ?He
> >> proposed running a pre-upgrade utility on each page to reserve the
> >> right amount of free space.
> >>
> >> http://archives.post
On Tue, Dec 1, 2009 at 10:45 PM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> If the pre-upgrade utility is something
>> that has to be run while the database is off-line, then it defeats the
>> point of an in-place upgrade. If it can be run while the database is
>> up, I fear it will need to be
On Tue, Dec 1, 2009 at 10:34 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > Well, there were quite a number of open issues relating to page
>> > conversion:
>> >
>> > ? ? ? ?o ?Do we write the old version or just convert on read?
>> > ? ? ? ?o ?How do we write pages that get larger on conversi
Robert Haas wrote:
If the pre-upgrade utility is something
that has to be run while the database is off-line, then it defeats the
point of an in-place upgrade. If it can be run while the database is
up, I fear it will need to be deeply integrated into the server. And
since we can't know the req
Robert Haas wrote:
> > Well, there were quite a number of open issues relating to page
> > conversion:
> >
> > ? ? ? ?o ?Do we write the old version or just convert on read?
> > ? ? ? ?o ?How do we write pages that get larger on conversion to the
> > ? ? ? ? ? new format?
> >
> > As I rember the pa
On Tue, Dec 1, 2009 at 9:31 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Tue, Dec 1, 2009 at 5:15 PM, Greg Stark wrote:
>> > On Tue, Dec 1, 2009 at 9:58 PM, decibel wrote:
>> >> What happened to the work that was being done to allow a page to be
>> >> upgraded
>> >> on the fly when it wa
Robert Haas wrote:
> On Tue, Dec 1, 2009 at 5:15 PM, Greg Stark wrote:
> > On Tue, Dec 1, 2009 at 9:58 PM, decibel wrote:
> >> What happened to the work that was being done to allow a page to be
> >> upgraded
> >> on the fly when it was read in from disk?
> >
> > There were no page level changes
On Tue, Dec 1, 2009 at 5:15 PM, Greg Stark wrote:
> On Tue, Dec 1, 2009 at 9:58 PM, decibel wrote:
>> What happened to the work that was being done to allow a page to be upgraded
>> on the fly when it was read in from disk?
>
> There were no page level changes between 8.3 and 8.4.
That's true, b
Greg Stark wrote:
> On Tue, Dec 1, 2009 at 9:58 PM, decibel wrote:
> > What happened to the work that was being done to allow a page to be upgraded
> > on the fly when it was read in from disk?
>
> There were no page level changes between 8.3 and 8.4.
Yea, we have the idea of how to do it (in ca
On Tue, Dec 1, 2009 at 9:58 PM, decibel wrote:
> What happened to the work that was being done to allow a page to be upgraded
> on the fly when it was read in from disk?
There were no page level changes between 8.3 and 8.4.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
24 matches
Mail list logo
