Re: [BUGS] BUG #6034: pg_upgrade fails when it should not. - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.
Date
Msg-id 201105241959.p4OJxxL05180@momjian.us
Whole thread Raw
In response to Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Robert Haas wrote:
> On Mon, May 23, 2011 at 2:57 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > Robert Haas wrote:
> >> On Mon, May 23, 2011 at 8:26 AM, Bruce Momjian <bruce@momjian.us> wrote:
> >> > Sorry, I was unclear. ?The question is whether the case of _name_ of the
> >> > locale is significant, meaning can you have two locale names that differ
> >> > only by case and behave differently?
> >>
> >> That would seem surprising to me, but I really have no idea.
> >>
> >> There's the other direction, too: two locales that vary by something
> >> more than case, but still have identical behavior. ?Maybe we just
> >> decide not to worry about that, but then why worry about this?
> >
> > Well, if we remove the check then people could easily get broken
> > upgrades by upgrading to a server with a different locale. ?A Google
> > search seems to indicate the locale names are case-sensitive so I am
> > thinking the problem is that the user didn't have exact locales, and
> > needs that to use pg_upgrade.
>
> I think you misread what I wrote, or I misexplained it, but never
> mind.  Matching locale names case-insensitively sounds reasonable to
> me, unless someone has reason to believe it will blow up.

OK, that's what I needed to hear.  I have applied the attached patch,
but only to 9.1 because  of the risk of breakage. (This was only the
first bug report of this, and we aren't 100% certain about the case
issue.)

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/check.c b/contrib/pg_upgrade/check.c
new file mode 100644
index 2117b7f..60c1fbb
*** a/contrib/pg_upgrade/check.c
--- b/contrib/pg_upgrade/check.c
*************** static void
*** 333,345 ****
  check_locale_and_encoding(ControlData *oldctrl,
                            ControlData *newctrl)
  {
!     if (strcmp(oldctrl->lc_collate, newctrl->lc_collate) != 0)
          pg_log(PG_FATAL,
                 "old and new cluster lc_collate values do not match\n");
!     if (strcmp(oldctrl->lc_ctype, newctrl->lc_ctype) != 0)
          pg_log(PG_FATAL,
                 "old and new cluster lc_ctype values do not match\n");
!     if (strcmp(oldctrl->encoding, newctrl->encoding) != 0)
          pg_log(PG_FATAL,
                 "old and new cluster encoding values do not match\n");
  }
--- 333,346 ----
  check_locale_and_encoding(ControlData *oldctrl,
                            ControlData *newctrl)
  {
!     /* These are often defined with inconsistent case, so use pg_strcasecmp(). */
!     if (pg_strcasecmp(oldctrl->lc_collate, newctrl->lc_collate) != 0)
          pg_log(PG_FATAL,
                 "old and new cluster lc_collate values do not match\n");
!     if (pg_strcasecmp(oldctrl->lc_ctype, newctrl->lc_ctype) != 0)
          pg_log(PG_FATAL,
                 "old and new cluster lc_ctype values do not match\n");
!     if (pg_strcasecmp(oldctrl->encoding, newctrl->encoding) != 0)
          pg_log(PG_FATAL,
                 "old and new cluster encoding values do not match\n");
  }

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Error compiling sepgsql in PG9.1
Next
From: Bruce Momjian
Date:
Subject: Re: Adding an example for replication configuration to pg_hba.conf