pgsql: pg_upgrade: Convert old visibility map format to new format.
pg_upgrade: Convert old visibility map format to new format.
Commit a892234f830e832110f63fc0a2afce2fb21d1584 added a second bit per
page to the visibility map, but pg_upgrade has been unaware of it up
until now. Therefore, a pg_upgrade from an earlier major release of
PostgreSQL to any commit preceding this one and following the one
mentioned above would result in invalid visibility map contents on the
new cluster, very possibly leading to data corruption. This plugs
that hole.
Masahiko Sawada, reviewed by Jeff Janes, Bruce Momjian, Simon Riggs,
Michael Paquier, Andres Freund, me, and others.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/7087166a88fe0c04fc6636d0d6d6bea1737fc1fb
Modified Files
--------------
src/bin/pg_upgrade/file.c | 154 +++++++++++++++++++++++++++++++++++++++
src/bin/pg_upgrade/pg_upgrade.h | 6 ++
src/bin/pg_upgrade/relfilenode.c | 48 +++++++++---
3 files changed, 197 insertions(+), 11 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Fri, Mar 11, 2016 at 05:36:34PM +0000, Robert Haas wrote:
pg_upgrade: Convert old visibility map format to new format.
Commit a892234f830e832110f63fc0a2afce2fb21d1584 added a second bit per
page to the visibility map, but pg_upgrade has been unaware of it up
until now. Therefore, a pg_upgrade from an earlier major release of
PostgreSQL to any commit preceding this one and following the one
mentioned above would result in invalid visibility map contents on the
new cluster, very possibly leading to data corruption. This plugs
that hole.Masahiko Sawada, reviewed by Jeff Janes, Bruce Momjian, Simon Riggs,
Michael Paquier, Andres Freund, me, and others.
I have tested the current git trees of all supported versions of
Postgres in all possible pg_upgrade combinations and they all worked
perfectly.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Tue, Apr 26, 2016 at 8:45 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 11, 2016 at 05:36:34PM +0000, Robert Haas wrote:
pg_upgrade: Convert old visibility map format to new format.
Commit a892234f830e832110f63fc0a2afce2fb21d1584 added a second bit per
page to the visibility map, but pg_upgrade has been unaware of it up
until now. Therefore, a pg_upgrade from an earlier major release of
PostgreSQL to any commit preceding this one and following the one
mentioned above would result in invalid visibility map contents on the
new cluster, very possibly leading to data corruption. This plugs
that hole.Masahiko Sawada, reviewed by Jeff Janes, Bruce Momjian, Simon Riggs,
Michael Paquier, Andres Freund, me, and others.I have tested the current git trees of all supported versions of
Postgres in all possible pg_upgrade combinations and they all worked
perfectly.
That's good!
All the commits related to this topic could use extra-careful review
and testing. If Masahiko-san got anything wrong, or I did, this could
eat people's data in ways that are very hard to track down.
So I hope we were both extra-smart while working on this patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 27, 2016 at 10:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Apr 26, 2016 at 8:45 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 11, 2016 at 05:36:34PM +0000, Robert Haas wrote:
pg_upgrade: Convert old visibility map format to new format.
Commit a892234f830e832110f63fc0a2afce2fb21d1584 added a second bit per
page to the visibility map, but pg_upgrade has been unaware of it up
until now. Therefore, a pg_upgrade from an earlier major release of
PostgreSQL to any commit preceding this one and following the one
mentioned above would result in invalid visibility map contents on the
new cluster, very possibly leading to data corruption. This plugs
that hole.Masahiko Sawada, reviewed by Jeff Janes, Bruce Momjian, Simon Riggs,
Michael Paquier, Andres Freund, me, and others.I have tested the current git trees of all supported versions of
Postgres in all possible pg_upgrade combinations and they all worked
perfectly.
Thank you for testing!
Good news for me.
That's good!
All the commits related to this topic could use extra-careful review
and testing. If Masahiko-san got anything wrong, or I did, this could
eat people's data in ways that are very hard to track down.
Yeah, we should test this feature in various ways, and I'm going to do so.
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers