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.
Re: [BUGS] BUG #6034: pg_upgrade fails when it should not. |
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: