nbianca
1월 18, 2023, 8:59오전
2
Ionut님,
버그 제보해 주셔서 감사합니다. 이 문제를 확인해 보겠습니다. 다만, 데이터베이스에 인덱스 관련 문제가 있는 것으로 보이며, 최근 마이그레이션에서 이를 수정하려고 시도했지만, 일부 문제는 사람의 개입 없이는 해결할 수 없습니다.
실패하는 마이그레이션을 도입한 커밋은 아마도 이 커밋일 것입니다:
committed 03:04AM - 13 Jan 23 UTC
In Discourse, there are many migration files where we CREATE INDEX CONCURRENTLY … which requires us to set disable_ddl_transaction!. Setting disable_ddl_transaction! in a migration file runs the SQL statements outside of a transaction. The implication of this is that there is no ROLLBACK should any of the SQL statements fail.
We have seen lock timeouts occuring when running CREATE INDEX CONCURRENTLY. When that happens, the index would still have been created but marked as invalid by Postgres.
Per the postgres documentation:
> If a problem arises while scanning the table, such as a deadlock or a uniqueness violation in a unique index, the CREATE INDEX command will fail but leave behind an “invalid” index. This index will be ignored for querying purposes because it might be incomplete; however it will still consume update overhead.
> The recommended recovery method in such cases is to drop the index and try again to perform CREATE INDEX CONCURRENTLY . (Another possibility is to rebuild the index with REINDEX INDEX CONCURRENTLY ).
When such scenarios happen, we are supposed to either drop and create the index again or run a REINDEX operation. However, I noticed today that we have not been doing so in Discourse. Instead, we’ve been incorrectly working around the problem by checking for the index existence before creating the index in order to make the migration idempotent. What this potentially mean is that we might have invalid indexes which are lying around in the database which PG will ignore for querying purposes.
This commits adds a migration which queries for all the
invalid indexes in the `public` namespace and reindexes them.
app.yml 파일을 편집하여 params 아래에 있는 version 키690e2f15ab9549486aaa6750e1093c1336bf17f2로 고정해 보실 수 있습니다. 해당 키가 주석 처리되어 있지 않도록 확인하세요!
그렇게 하면 모든 것이 정상적으로 시작되고 중복된 vuejs 태그를 제거할 수 있어야 합니다. 하지만 중복된 태그가 사용 중이라면 원치 않는 부작용이 발생할 수 있습니다. 더 나은 해결책을 찾기 위해 노력하겠지만, 그때까지는 이 방법으로 작동할 것입니다.