nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Unsupported collation error - how serious is it

Andrew Laden

Hey all

So I am finally getting around to upgrading my jira from LTS 7.13.6 to LTS 8.6.5. Doing my test system first so I can play a little with it.

During the upgrade I got the "You are using an unsupported postgres72 collation" error. (we are on postgres9.6 so the message itself is confusing)

Led me to https://confluence.atlassian.com/jirakb/unsupported-collation-error-thrown-in-jira-server-using-postgresql-776657961.html

We are using en_US.UTF-8 which I guess used to be fine but is no longer supported.

The interesting thing is that after that message. I shut down jira and restarted it again, and it came up without complaints.

So before I dump my database, re-create the database, and restore the data, (or worse do the XML thing) Just how serious is this error?

Thanks

Accepted answers

Nic Brough -Adaptavist-

I can't say it's serious or not, the setting is not the only factor in making that judgement.

Take a really simple case - your people all work in more western European languages that can all write everything with ASCII codes numbered below 256 (this includes a much wider range of characters than English speakers, even when expanded out to American, Australian or even Indian English variants). Collation in them is utterly irrelevant, the computers are happy with cedillas, umlauts, accents and the rest.

But when you start to talk in Turkish, Latvian or Farsi/Persian for example, it starts to fail, badly. (And bear in mind this includes people's real names).

UTF encoding draws a lot more in, and hence is a very good idea.

The good news is that the wrong collation will not break your data. There's no data loss, nothing will corrupt, crash or disappear. You won't have performance or backup issues.

But you could easily run into "my search won't work", or, worse, "I can't log in"

All comments

Sachin_q0v8o8

hello @Andrew Laden ,we have seen this reported during our JIRA upgrades (8.5.3), as it hits this and prompts us to ignore it and continue. (which we did). We have continued to disregard it and had no impact on any functionality. So, I don't think this is a serious issue.

This behavior looks to be an occurrence of the following bug report, you can upvote and add a comment there if you like:

JRASERVER-46026 - JIRA is unable to check collation on certain JDBC URLs

Andrew Laden

Took a look. We arent seeing the same thing. In that bug it cant determine the collation.

In my case its determining the collation, it just doesn't like it anymore.

Nic Brough -Adaptavist-

I can't say it's serious or not, the setting is not the only factor in making that judgement.

But when you start to talk in Turkish, Latvian or Farsi/Persian for example, it starts to fail, badly. (And bear in mind this includes people's real names).

UTF encoding draws a lot more in, and hence is a very good idea.

The good news is that the wrong collation will not break your data. There's no data loss, nothing will corrupt, crash or disappear. You won't have performance or backup issues.

But you could easily run into "my search won't work", or, worse, "I can't log in"

Andrew Laden

Thanks. I had a feeling it was something like that. Given my environment (US company, etc), it doesn't sound to critical to change it. I'd rather get the upgrade to the LTS complete. Having to add in a export/restore at the same time is more overhead that I would not want to deal with just now.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-core

postgres