Обсуждение: 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(-)
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
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
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. +