xorm introduced some changes in https://github.com/go-xorm/xorm/pull/824 and https://github.com/go-xorm/xorm/pull/876 which by default will use public as the postgres schema and this was a breaking change compared to before. Grafana has implemented a custom postgres dialect so above changes wasn't a problem here. However, Grafana's custom database migration was using xorm dialect to check if the migration table exists or not. For those using a custom search_path (schema) in postgres configured on server, database or user level the migration table check would not find the migration table since it was looking in public schema due to xorm changes above. This had the consequence that Grafana's database migration failed the second time since migration had already run migrations in another schema. This change will make xorm use an empty default schema for postgres and by that mimic the functionality of how it was functioning before xorm's changes above. Fixes #16720 Co-Authored-By: Carl Bergquist <carl@grafana.com>
Name |
Last commit
|
Last Update |
---|---|---|
.. | ||
api | Loading commit data... | |
bus | Loading commit data... | |
cmd | Loading commit data... | |
components | Loading commit data... | |
events | Loading commit data... | |
extensions | Loading commit data... | |
infra | Loading commit data... | |
login | Loading commit data... | |
middleware | Loading commit data... | |
models | Loading commit data... | |
plugins | Loading commit data... | |
registry | Loading commit data... | |
services | Loading commit data... | |
setting | Loading commit data... | |
tsdb | Loading commit data... | |
util | Loading commit data... |