fix: DB migration script

[hubertdeng123]

This improves the logic to wait for postgres server to be up and running. It also fixes a typo 😬

It seems like using pg_isready in the install script was not a reliable way to wait for the postgres server to be up and ready to accept connections. So, I used a few lines that were previously working from the upgrade-postgres.sh script. Additionally, the exec command was missing when removing the specific db index causing issues.

Follow up to #2758

[BYK]

Can you explain a bit more why the old one was broken? (just trying to learn 🙂)

[meenzen]

This fixed #2780 for me, logs before applying this patch:

▶ Setting up / migrating database ...
Container sentry-self-hosted-postgres-1  Creating
Container sentry-self-hosted-postgres-1  Created
Container sentry-self-hosted-postgres-1  Starting
Container sentry-self-hosted-postgres-1  Started
Error in install/set-up-and-migrate-database.sh:5.
'timeout 90s bash -c "until $dc exec postgres pg_isready ; do sleep 5 ; done"' exited with status 124
-> ./install.sh:main:35
--> install/set-up-and-migrate-database.sh:source:5

Envelope from file sentry-envelope-bcbbcc6337e1888ef4ec69d52c59328b dispatched
Cleaning up...

[jwaschkau]

Fix works for me.

[hubertdeng123]

Can you explain a bit more why the old one was broken? (just trying to learn 🙂)

@BYK I've added some more info in the description of the PR. I couldn't quite wrap my head around the error around waiting for the postgres server to become healthy and ready for connections, since it works locally for me. It even passed CI here. I just opted for an approach that we used previously that seemed to work more broadly across platforms.

[roskakori]

@hubertdeng123 From what I understand the issue was that by default pg_isready uses "root" as username, which according to docker compose logs postgres results in the following error:

postgres-1  | 2024-02-09 21:34:59.724 UTC [1] LOG:  database system is ready to accept connections
postgres-1  | 2024-02-09 21:34:59.780 UTC [46] FATAL:  role "root" does not exist

The reason for that seems to be that the docker container uses "postgres" as user.

Shouldn't it have been enough to just add this user, something like:

pg_isready --username=postgres

as described in the pg_isready documentation?

[hubertdeng123]

@roskakori Did replacing pg_isready with pg_isready --username=postgres work for you? I tried that but the issue still persisted where I was able to reproduce it.

[toto4ds]

It didn’t help me, now I have this error:

ERROR: cannot drop index sentry_groupedmessage_project_id_id_515aaa7e_uniq because constraint sentry_groupedmessage_project_id_id_515aaa7e_uniq on table sentry_groupedmessage requires it
HINT: You can drop constraint sentry_groupedmessage_project_id_id_515aaa7e_uniq on table sentry_groupedmessage instead.
Error in install/set-up-and-migrate-database.sh:13.
'$dc exec postgres psql -qAt -U postgres -c "DROP INDEX sentry_groupedmessage_project_id_id_515aaa7e_uniq;"' exited with status 1
-> ./install.sh:main:35
--> install/set-up-and-migrate-database.sh:source:13

[IdahoPL]

Fix worked for me.

[toto4ds]

Fix worked for me.

most likely this is an unrelated problem, maybe you just didn't have this INDEX or I don't know why my postgres can't bite the INDEX

[hubertdeng123]

@toto4ds What version of self-hosted are you upgrading from? I'm wondering if that error may be due to coming off of an older version of Sentry that requires that index.

[toto4ds]

@hubertdeng123 From 24.1.1 to 24.1.2
I always try to update to the new version
And as I see, this drop appeared in the version 24.1.2

docker compose exec postgres psql -qAt -U postgres -c "SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'sentry_groupedmessage';"
sentry_groupedmessage_pkey|CREATE UNIQUE INDEX sentry_groupedmessage_pkey ON public.sentry_groupedmessage USING btree (id)
sentry_groupedmessage_project_id_29374dd7_uniq|CREATE UNIQUE INDEX sentry_groupedmessage_project_id_29374dd7_uniq ON public.sentry_groupedmessage USING btree (project_id, short_id)
sentry_groupedmessage_project_id_id_515aaa7e_uniq|CREATE UNIQUE INDEX sentry_groupedmessage_project_id_id_515aaa7e_uniq ON public.sentry_groupedmessage USING btree (project_id, id)
sentry_groupedmessage_30e0497b|CREATE INDEX sentry_groupedmessage_30e0497b ON public.sentry_groupedmessage USING btree (active_at)
sentry_groupedmessage_6db435f3|CREATE INDEX sentry_groupedmessage_6db435f3 ON public.sentry_groupedmessage USING btree (logger)
sentry_groupedmessage_79aa7116|CREATE INDEX sentry_groupedmessage_79aa7116 ON public.sentry_groupedmessage USING btree (first_seen)
sentry_groupedmessage_956acbd7|CREATE INDEX sentry_groupedmessage_956acbd7 ON public.sentry_groupedmessage USING btree (last_seen)
sentry_groupedmessage_9acb4454|CREATE INDEX sentry_groupedmessage_9acb4454 ON public.sentry_groupedmessage USING btree (status)
sentry_groupedmessage_b098ad43|CREATE INDEX sentry_groupedmessage_b098ad43 ON public.sentry_groupedmessage USING btree (project_id)
sentry_groupedmessage_c64ddfc1|CREATE INDEX sentry_groupedmessage_c64ddfc1 ON public.sentry_groupedmessage USING btree (resolved_at)
sentry_groupedmessage_c9e9a848|CREATE INDEX sentry_groupedmessage_c9e9a848 ON public.sentry_groupedmessage USING btree (level)
sentry_groupedmessage_d26bbf96|CREATE INDEX sentry_groupedmessage_d26bbf96 ON public.sentry_groupedmessage USING btree (times_seen)
sentry_groupedmessage_de5f52a0|CREATE INDEX sentry_groupedmessage_de5f52a0 ON public.sentry_groupedmessage USING btree (first_release_id)
sentry_groupedmessage_logger_993cb6d5_like|CREATE INDEX sentry_groupedmessage_logger_993cb6d5_like ON public.sentry_groupedmessage USING btree (logger varchar_pattern_ops)
sentry_groupedmessage_project_id_515aaa7e_idx|CREATE INDEX sentry_groupedmessage_project_id_515aaa7e_idx ON public.sentry_groupedmessage USING btree (project_id, id)
sentry_groupedmessage_project_id_7f8c0ae5_idx|CREATE INDEX sentry_groupedmessage_project_id_7f8c0ae5_idx ON public.sentry_groupedmessage USING btree (project_id, first_release_id)
sentry_groupedmessage_project_id_status_last_s_6b8195a7_idx|CREATE INDEX sentry_groupedmessage_project_id_status_last_s_6b8195a7_idx ON public.sentry_groupedmessage USING btree (project_id, status, last_seen, id)
sentry_groupedmessage_project_id_type_status_l_074196b6_idx|CREATE INDEX sentry_groupedmessage_project_id_type_status_l_074196b6_idx ON public.sentry_groupedmessage USING btree (project_id, status, type, last_seen, id)
sentry_groupedmessage_type_de66b3a2|CREATE INDEX sentry_groupedmessage_type_de66b3a2 ON public.sentry_groupedmessage USING btree (type)
sentry_groupedmessage_project_id_status_substa_c95bb62c_idx|CREATE INDEX sentry_groupedmessage_project_id_status_substa_c95bb62c_idx ON public.sentry_groupedmessage USING btree (project_id, status, substatus, type, last_seen, id)
sentry_groupedmessage_project_id_status_substa_fbe106b6_idx|CREATE INDEX sentry_groupedmessage_project_id_status_substa_fbe106b6_idx ON public.sentry_groupedmessage USING btree (project_id, status, substatus, last_seen, id)
sentry_groupedmessage_project_id_status_substa_78b9cc1c_idx|CREATE INDEX sentry_groupedmessage_project_id_status_substa_78b9cc1c_idx ON public.sentry_groupedmessage USING btree (project_id, status, substatus, id)
sentry_groupedmessage_status_substatus_id_e00e92ae_idx|CREATE INDEX sentry_groupedmessage_status_substatus_id_e00e92ae_idx ON public.sentry_groupedmessage USING btree (status, substatus, id)
sentry_groupedmessage_status_substatus_first_seen_99773cf6_idx|CREATE INDEX sentry_groupedmessage_status_substatus_first_seen_99773cf6_idx ON public.sentry_groupedmessage USING btree (status, substatus, first_seen)

[roskakori]

@hubertdeng123

Did replacing pg_isready with pg_isready --username=postgres work for you? I tried that but the issue still persisted where I was able to reproduce it.

I didn't try. I just saw that the diff was rather big for such a seemingly simple issue, took a look at the pg_isready manual and added it as suggestion.

Sorry to hear that it did not work.

[crinjes]

@roskakori Did replacing pg_isready with pg_isready --username=postgres work for you? I tried that but the issue still persisted where I was able to reproduce it.

This did not work for me.

[toto4ds]

@hubertdeng123
24.2.0 work for me

[SeanSith]

Is there any way to have this use the Django connection details in the future, rather than assuming that your database is running in Docker? We're using an external database (RDS).

[aldy505]

Is there any way to have this use the Django connection details in the future, rather than assuming that your database is running in Docker? We're using an external database (RDS).

@SeanSith see #2804