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 completely
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
On Sat, Feb 13, 2010 at 3:34 AM, Greg Smith g...@2ndquadrant.com 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
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-place
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 we want to
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 requiring a
Simon Riggs si...@2ndquadrant.com 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.
Simon Riggs si...@2ndquadrant.com 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
On Thu, 2010-02-11 at 11:27 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs si...@2ndquadrant.com 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
On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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
On Thu, Feb 11, 2010 at 2:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
Avoiding a scan before running pg_upgrade is just a performance
optimisation.
But using
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 covers
On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Robert Haas escribió:
On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Simon Riggs si...@2ndquadrant.com 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
17 matches
Mail list logo
