You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Database migration to 5.4.0 breaks compatibility with postgresql 11.
Steps to reproduce
Be running postgresql 11.
Upgrade to mattermost-server 5.4.0. I upgraded from 5.3.1, so the issue may be present in larger version jumps.
Restart the platform binary
Attempt to send a message. I did not try anything other than the Town Square, so DMs may or may not be affected.
Expected behavior
When upgrading from 5.3.1 to 5.4.0 while using postgresql 11, the upgrade succeeds, but sending messages no longer works.
Observed behavior (that appears unintentional)
The API endpoint /api/v4/posts returns a 500 with the following error message:
pq: could not access file \"$libdir/dict_snowball\": No such file or directory
Possible fixes
Through looking at the postgresql source code, I saw that dict_snowball seems to be a feature specific to postgresql 11. I downgraded to postgresql 10 which fixed the problem.
The text was updated successfully, but these errors were encountered:
Hi @matoro, a community member took a look at this and said that this is most likely not an issue in Mattermost.
It sounds like this would be an issue with your PostgreSQL setup (please take a look at this Q&A). Also, PostgreSQL 11 documentation on snowball dictionary doesn't mention deprecation or anything else notable.
Summary
Database migration to 5.4.0 breaks compatibility with postgresql 11.
Steps to reproduce
Expected behavior
When upgrading from 5.3.1 to 5.4.0 while using postgresql 11, the upgrade succeeds, but sending messages no longer works.
Observed behavior (that appears unintentional)
The API endpoint
/api/v4/posts
returns a 500 with the following error message:Possible fixes
Through looking at the postgresql source code, I saw that dict_snowball seems to be a feature specific to postgresql 11. I downgraded to postgresql 10 which fixed the problem.
The text was updated successfully, but these errors were encountered: