From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: pg_upgrade cleanup |
Date: | 2015-05-16 18:49:08 |
Message-ID: | 20150516184908.GC16100@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 16, 2015 at 12:21:12PM -0400, Noah Misch wrote:
> On Thu, May 14, 2015 at 10:06:11PM -0400, Bruce Momjian wrote:
> > On Thu, May 14, 2015 at 09:56:53PM -0400, Bruce Momjian wrote:
> > > This patch makes pg_upgrade controldata checks more consistent, and adds
> > > a missing check for float8_pass_by_value.
> >
> > Sorry, I should have mentioned I applied this patch to head. It isn't
> > significant enough to backpatch.
>
> A float8_pass_by_value match is unnecessary, and requiring it creates needless
> hassle for users. Switching between USE_FLOAT8_BYVAL binaries and
> !USE_FLOAT8_BYVAL binaries requires an initdb to get different values in
> pg_type.typbyval and pg_attribute.attbyval. pg_upgrade's use of pg_dump to
> migrate catalog content addresses that fine. Note that
> check_for_isn_and_int8_passing_mismatch() exists because pg_upgrade has
> allowed source and destination clusters to differ in USE_FLOAT8_BYVAL.
What we had was checking for float8_pass_by_value, but did nothing with
it, so I assumed we had lost the check somehow. I will remove detecting
and checking of that value. Thanks.
> The rest of this change is opaque to me. "More consistent" with what? The
> old use of the "tli" variable sure looked like a bug, considering the variable
> was never set to anything but zero. What is the anticipated behavior change?
The problem was that the option checking was not in a consistent order,
so there was no easy easy to make sure everything was being processed
properly. The new ordering is consistent.
I thought the tli was a harmless cleanup but I now see it was passing a
zero timeline to pg_resetxlog. The only reason that worked was because
pg_resetxlog ignores a timeline that is less than our current one, and
zero was always less than the timeline so pg_resetxlog was making no
timeline change at all. I will clean that up too in backbranches as it
is to odd. (I think it was broken by
038f3a05092365eca070bdc588554520dfd5ffb9).
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-05-16 19:23:09 | Re: pg_upgrade cleanup |
Previous Message | Tom Lane | 2015-05-16 17:05:27 | Re: Run pgindent now? |