Skip site navigation (1) Skip section navigation (2)

Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
Date: 2010-02-11 16:27:38
Message-ID: 10339.1265905658@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)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 similar situation where that risk has
> already materialized into damage for a user in at least one case.

You cited no such case; you merely hypothesized that it could happen.

As for the alleged risks involved, keeping the tqual support for MOVED
bits cannot create any data-loss risks that haven't existed right along
in every previous release.  But depending on MOVED bits to be reliably
gone after a pg_upgrade would introduce a very obvious data loss risk
that wasn't there before, namely that pg_upgrade misses one.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-02-11 16:27:43
Subject: Re: TCP keepalive support for libpq
Previous:From: Andrew DunstanDate: 2010-02-11 16:24:05
Subject: Re: a common place for pl/perlu modules

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2010-02-11 17:04:41
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Tom LaneDate: 2010-02-11 15:55:28
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group