Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
| От | Tom Lane |
|---|---|
| Тема | Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while |
| Дата | |
| Msg-id | 10339.1265905658@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while (Simon Riggs <simon@2ndQuadrant.com>) |
| Ответы |
Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL
(which was known for a little while
|
| Список | pgsql-hackers |
Simon Riggs <simon@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 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
В списке pgsql-hackers по дате отправления: