Greg Stark wrote:
> On Tue, Feb 16, 2010 at 2:04 PM, Bruce Momjian wrote:
> > The MOVE_* bits go away after a while by vacuum and there is an easy
> > solution for 9.1 --- vacuum everything in 9.0. ?Where things really get
> > hard is when we have to support two page formats or two data formats in
On Tue, Feb 16, 2010 at 2:04 PM, Bruce Momjian wrote:
> The MOVE_* bits go away after a while by vacuum and there is an easy
> solution for 9.1 --- vacuum everything in 9.0. Where things really get
> hard is when we have to support two page formats or two data formats in
> the same database. You
Greg Smith wrote:
> If you think through the implications of that far enough, eventually you
> start to realize that you really can't even add a feature that requires
> an in-place upgrade hack to fix without first having the code that
> performs said hack done. Otherwise you're never completel
On Sat, Feb 13, 2010 at 3:34 AM, Greg Smith wrote:
> Robert Haas wrote:
>> Recording some bookkeeping information in pg_class so that pg_migrator can
>> tell what's going on
>> at a glance seems like the right approach, but I'm fuzzy on the details.
>
> November of 2008 was a pretty good month for
Robert Haas wrote:
Recording some bookkeeping information in pg_class so that pg_migrator can tell
what's going on
at a glance seems like the right approach, but I'm fuzzy on the details.
November of 2008 was a pretty good month for me, so I enjoyed this
flashback to it. That's when the p
Simon Riggs writes:
> I understand that the final process to switch from one release to
> another needs to be quick. Before that we can have any number of
> preparatory steps. One of those is backup, if you're sane. Another one
> should be a preparatory step that can be performed while the databas
Robert Haas escribió:
> On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >
> >> I'm not quite sure how to do this in practice. One idea would be to
> >> record the catversion that created the relation in pg_class, and make
> >> pg_upgrade preserve the catversio
On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> I'm not quite sure how to do this in practice. One idea would be to
>> record the catversion that created the relation in pg_class, and make
>> pg_upgrade preserve the catversion, but make CLUSTER or similar bump
Robert Haas escribió:
> I'm not quite sure how to do this in practice. One idea would be to
> record the catversion that created the relation in pg_class, and make
> pg_upgrade preserve the catversion, but make CLUSTER or similar bump
> it on successful completion. But I'm not sure if that cover
On Thu, Feb 11, 2010 at 2:03 PM, Simon Riggs wrote:
> On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
>> On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs wrote:
>> > Avoiding a scan before running pg_upgrade is just a performance
>> > optimisation.
>>
>> But using pg_upgrade AT ALL is also a pe
Simon Riggs writes:
> Avoiding a scan before running pg_upgrade is just a performance
> optimisation. I don't think we should be optimising an upgrade in this
> way, especially since sane people do database backups before upgrade
> anyway. The optimisation is misplaced. The fact that we are active
On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
> On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs wrote:
> > Avoiding a scan before running pg_upgrade is just a performance
> > optimisation.
>
> But using pg_upgrade AT ALL is also a performance optimization; in
> fact AFAICS it's the only reas
On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs wrote:
> Avoiding a scan before running pg_upgrade is just a performance
> optimisation.
But using pg_upgrade AT ALL is also a performance optimization; in
fact AFAICS it's the only reason to use pg_upgrade. So if you take
that away there's no reason
On Thu, 2010-02-11 at 11:27 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > You still have to perform a backup of the database prior to upgrade and
> > that also must scan the whole database, so the overall time to upgrade
> > will still vary according to database size. So I don't see any overall
Simon Riggs writes:
> You still have to perform a backup of the database prior to upgrade and
> that also must scan the whole database, so the overall time to upgrade
> will still vary according to database size. So I don't see any overall
> benefit, just risk, and I cited a similar situation wher
Simon Riggs writes:
> This would only happen if a VACUUM FULL had been run on the pre-9.0
> database and it had failed part way through.
If that were true, you might have an argument, but it isn't. VACUUM
FULL was never very careful about getting rid of all MOVED_xxx bits.
See the comments for u
On Thu, 2010-02-11 at 14:53 +0200, Heikki Linnakangas wrote:
> Andres Freund wrote:
> > On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
> >> We should remove the moved in/off flag bits and make it a part of the
> >> upgrade process to ensure the absence of those states.
> > Essentially req
Andres Freund wrote:
> On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
>> On Mon, 2010-02-08 at 04:33 +, Tom Lane wrote:
>>> We still have to retain all code that copes with finding
>>> HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples. This
>>> can't be removed as long as
On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
> On Mon, 2010-02-08 at 04:33 +, Tom Lane wrote:
> > We still have to retain all code that copes with finding
> > HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples. This
> > can't be removed as long as we want to support in-p
On Mon, 2010-02-08 at 04:33 +, Tom Lane wrote:
> We still have to retain all code that copes with finding
> HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples. This
> can't be removed as long as we want to support in-place update from
> pre-9.0 databases.
This doesn't seem to be a
20 matches
Mail list logo
