-
-
Notifications
You must be signed in to change notification settings - Fork 364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pq: relation "UQE_migrations_name" already exists #2038
Comments
thanks for testing and the trace logs :) |
@schewara can you exec the sql: it tells us what migrations did already run PS: a goodie would be if you could tell us the current schema of the migrations table too |
@6543 Sorry, should have added that already in the initial report. From further digging, the problem seems to be schema related.
But as one can see in the extended logs below the SQL statements are explicitely targeting the So if someone uses the PostgreSQL secure schema usage pattern this currently seems to be broken. updated logs with activated
Database table infos:
|
looking at gitea who also use xorm they do have a workaround: https://github.com/go-gitea/gitea/blob/55532061c83d38d33ef48bdc5eeac0f652844e8a/models/db/engine.go#L104-L120 ... but it should be solved upstream once and for all :/ |
upstream issue: https://gitea.com/xorm/xorm/issues/2317 this is not something we can just hotfix for v1.0.0 ... without also introduce much new code that can have bugs ... so I move that onto the next milestone :/ |
@schewara where in the connection string is the schema introduced ? |
@6543 based on https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS there is no parameter available for setting any schema as part of the uri. I will give it another spin with some random name, as well as not setting it at all and see if the behavior changes. But based on other setups, where 2 apps are accessing the same database with different application names I do not expect to see any differences. |
Quick update from my end: I tested now the following scenarios without success
All 3 variations and combinations are still targeting the
As we are using the postgres containers from Crunchy Data, the database initialization is slightly different as the one in the official postgres image The initialization of the crunchy containers happens as part of But in the end the same behavior can be exactly reproduced by creating an additional user and database in any existing postgres setup with the following statements, replacing
with custom values and connecting with that user to the database. CREATE USER "PG_USER" LOGIN;
ALTER USER "PG_USER" PASSWORD 'PG_PASSWORD';
CREATE DATABASE "PG_DATABASE";
GRANT ALL PRIVILEGES ON DATABASE "PG_DATABASE" TO "PG_USER";
CREATE SCHEMA IF NOT EXISTS "PG_USER"; By default the @6543 I also had a look at the upstream Issue and the information
is incorrect, as the |
Here a full example to reproduce the issue with the standard postgres container
Performing the same steps with the image tag |
I close this issue as code changed a loot now - if similar issue ocure, just create a new issue and link to this one |
Component
server
Describe the bug
After upgrading the server from
v0.15
tov1.0
woodpecker only returns 404 and the following entries are continuously written to the log outputNo other changes were made besides the update of the docker image.
System Info
Additional context
trace log:
Validations
next
version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]upstream issue: https://gitea.com/xorm/xorm/issues/2317
The text was updated successfully, but these errors were encountered: