Upgrade issue between Q1 and Q2: "public.gin_trgm_ops" does not exist
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
blocks
relates to
Checklist
hideTestRail: Results
Activity

jrootJuly 14, 2020 at 7:20 PM
I was able to successfully upgrade now from Q1 to Q2 with mod-cal and mod-orders RMB updates.

Ann-Marie BreauxJuly 13, 2020 at 1:21 PM
Great - thanks very much,

Julian LadischJuly 13, 2020 at 10:05 AM
If sysOps use latest platform-complete or platform-core to run the upgrade they are safe.
The first module in
https://github.com/folio-org/platform-complete/blob/q2-2020/install.json
is mod-orders-storage 11.0.3 that has the RMB fix.
The first module in
https://github.com/folio-org/platform-core/blob/q2-2020/install.json
is mod-calendar 1.9.1 that has the RMB fix.
If the first module fixes the issue all following modules upgrade successfully even if they use old RMB versions.
I've added an upgrade considerations entry to the Goldenrod release notes:
https://folio-org.atlassian.net/wiki/pages/viewpage.action?pageId=5210318#Q22020(Goldenrod)ReleaseNotes(InProgress)-ImportantUpgradeConsiderations

Ann-Marie BreauxJuly 13, 2020 at 5:40 AM
Hi and We're trying to figure out if any additional work is needed for MODORGSTOR-74, MODCONF-54, or MODPERMS-88 or they can just be closed. With regards to 's concern a few comments above - would there be a need to upgrade mod-orders-storage before the other affected apps? If that's required, we definitely need to document in the release notes on the wiki. Plus I'm wondering if that requirement might cause issues for upgrading libraries, especially since MODPERMS is one of the affected apps, and it usually needs to be deployed early in the sequencing (I think). Thank you!
cc:

Ann-Marie BreauxJuly 13, 2020 at 5:31 AM
Closing this ticket.
Details
Assignee
Julian LadischJulian LadischReporter
jrootjrootLabels
Priority
P2Story Points
0Sprint
NoneDevelopment Team
Core: PlatformFix versions
Release
Q2 2020Affected Institution
TAMUTestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Assignee

Reporter

Upgraded release of mod-orders-storage from v10.0.2 to v11.0.1 for an existing Diku tenant with data.
The request sent to Okapi was this, with reference and sample data set to true:
Also tried, after rolling back the DB instances, with sample and reference data set to false, with the same error.
Okapi returned the following error during the tenant API call:
mod-orders-storage logs: