pgsql: Fix pg_type.typlen for newly-revived line type.
Fix pg_type.typlen for newly-revived line type.
Commit 261c7d4b653bc3e44c31fd456d94f292caa50d8f removed the "m" field
from struct LINE, but neglected to make pg_type.h's idea of the type's
size match. This resulted in reading past the end of palloc'd LINE
values when inserting them into tuples etc. In principle that could
cause a SIGSEGV, though the odds of detectable problems seem low.
Bump catversion since this makes an incompatible on-disk format change.
Note that if the line type had been in use in the field, this would
break pg_upgrade'ability of databases containing line values; but
it seems unlikely that there are any (they'd have had to be compiled
with -DENABLE_LINE_TYPE).
Spotted by Andres Freund.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/3727afafeef69088456acc3f6257360315220a20
Modified Files
--------------
src/include/catalog/catversion.h | 2 +-
src/include/catalog/pg_type.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Tom Lane wrote:
Note that if the line type had been in use in the field, this would
break pg_upgrade'ability of databases containing line values; but
it seems unlikely that there are any (they'd have had to be compiled
with -DENABLE_LINE_TYPE).
Should we add a test to pg_upgrade --check mode?
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Tom Lane wrote:
Note that if the line type had been in use in the field, this would
break pg_upgrade'ability of databases containing line values; but
it seems unlikely that there are any (they'd have had to be compiled
with -DENABLE_LINE_TYPE).
Should we add a test to pg_upgrade --check mode?
I doubt it's worth it. Anybody who was enabling the old code is pretty
well screwed no matter what. They can't upgrade with a plain pg_dump
either, since the I/O format is different.
What we do need, probably, is a warning about the incompatibility in the
release notes.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Mon, May 5, 2014 at 03:00:47PM -0400, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Tom Lane wrote:
Note that if the line type had been in use in the field, this would
break pg_upgrade'ability of databases containing line values; but
it seems unlikely that there are any (they'd have had to be compiled
with -DENABLE_LINE_TYPE).Should we add a test to pg_upgrade --check mode?
I doubt it's worth it. Anybody who was enabling the old code is pretty
well screwed no matter what. They can't upgrade with a plain pg_dump
either, since the I/O format is different.What we do need, probably, is a warning about the incompatibility in the
release notes.
I added a check to pg_upgrade to error out on previous 'line' data type
usage because pg_upgrade would have blindly upgraded the
non-binary-compatible data. I also added a mention of this in the
9.4 release notes.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +