| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, Florian Pflug <fgp(at)phlo(dot)org>, Ants Aasma <ants(at)cybertec(dot)at>, Andres Freund <andres(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Enabling Checksums |
| Date: | 2013-04-17 17:29:18 |
| Message-ID: | 4295.1366219758@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Uh, not sure how pg_upgrade would detect that as the version number is
> not stored in pg_controldata, e.g.:
> Data page checksums: enabled/disabled
That seems pretty shortsighted. The field probably ought to be defined
as containing a checksum algorithm ID number, not a boolean.
But having said that, I'm not sure why this would be pg_upgrade's
problem. By definition, we do not want pg_upgrade running around
looking at individual data pages. Therefore, whatever we might do
about checksum algorithm changes would have to be something that can be
managed on-the-fly by the newer server.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-04-17 18:06:12 | Re: erroneous restore into pg_catalog schema |
| Previous Message | Bruce Momjian | 2013-04-17 17:24:42 | Re: Enabling Checksums |