I just upgraded the backend db from Postgres 9.6 to 12.7
Then I got this error /app/bin/docker-entrypoint: line 35: 7 Segmentation fault (core dumped) /app/manage.py db upgrade.
I don’t know if it’s because of the db version upgrade :thinking:

What command are you running that results in the seg fault?

/app/manage.py db upgrade
as in

server() {
  /app/manage.py db upgrade
  # Recycle gunicorn workers every n-th request. See http://docs.gunicorn.org/en/stable/settings.html#max-requests for more details.
  MAX_REQUESTS=${MAX_REQUESTS:-1000}
  MAX_REQUESTS_JITTER=${MAX_REQUESTS_JITTER:-100}
  exec /usr/local/bin/gunicorn -b 0.0.0.0:5000 -c config_gunicorn.py --name redash -w${REDASH_WEB_WORKERS:-4} redash.wsgi:app --max-requests $MAX_REQUESTS --max-requests-jitter $MAX_REQUESTS_JITTER
}

Are any migrations actually required? What steps did you follow before updating the postgres version? I would assume that the migrations are intended to be run on the version of the database where the migration was created. i.e. you should run the migration, then update the postgres version.

1 Like

there was no migration, i didn’t upgrade my redash or anything
/app/manage.py db upgrade is just there as a standard procedure before starting the server
it’s been there since the start of our redash journey 5 years ago. never caused any issues until i upgrade postgres (aws rds mandates this version upgrade. they will stop supporting postgres 9 very soon)

It sounds like you updated the PostgreSQL software version. If that’s the case, then it’s likely pretty unhappy as the format of the data on the disk changed a lot between those two versions.

For that kind of thing, you’ll probably want to do a dump of the PostgreSQL data from PostgreSQL 9.6 first, then load it into a fresh new PostgreSQL 12 instance.

If you still have a backup of your Redash postgresql-data directory directory from before you did the upgrade, you could run the old PostgreSQL version using that. You’d use pg_dumpall to dump the data out to a sql file.

Then you could load that .sql file into PostgreSQL 12, and it should work ok. In theory.

Obviously, take backups on the way through when trying it out though. :slight_smile:

1 Like

after further investigation, i have 99.5% ruled out PostgreSQL 12 being the issue:

  1. under PostgreSQL 12, there are no errors spinning up containers using previously built (~Aug 2021) images
  2. this error ONLY occurs with newly built images

so my guess is some dependencies got updated between August and now :sob:

So I’m clear: are you running the metadata database as a service within docker-compose? Or did you store it in a different place (redshift e.g.)

It’s a regular postgresql database hosted on RDS.

Cool. Let’s rule out what’s causing the issue. In a stock docker development environment, what happens if you update the postgres image from postgres:9.5-alpine to postgres:12-bullseye? Does it work?

When I tried I first saw this in the logs:

postgres_1   | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1   | 
postgres_1   | 2021-12-08 20:25:06.553 UTC [1] FATAL:  database files are incompatible with server
postgres_1   | 2021-12-08 20:25:06.553 UTC [1] DETAIL:  The data directory was initialized by PostgreSQL version 9.5, which is not compatible with this version 12.9 (Debian 12.9-1.pgdg110+1).

So I ran docker-compose down && docker-compose up -d && docker-compose run --rm server create_db and then it loaded fine.

Redash now loads and runs as expected.

i’m definitely having a different issue right now :joy:
i’m running docker-compose up using my 7-week old image of postgres:9.5-alpine and it gave me

worker_1     | /app/bin/docker-entrypoint: line 28:     8 Segmentation fault      (core dumped) /app/manage.py db upgrade
scheduler_1  | /app/bin/docker-entrypoint: line 11:     7 Segmentation fault      (core dumped) /app/manage.py db upgrade

Yeah that seems unrelated. Can you make a backup of your current database, spin up a fresh instance of V10.1, restore with the backup you made, and then upgrade to Postgres 12?

1 Like

i may have to switch back to the official redash first
i’m using a slightly-customized version on top of the mozilla fork m30 tag, don’t even know where to start at this point :man_facepalming:

i’ll do a docker-compose build --no-cache and see if there is a build issue…

I don’t think their fork is so much different than getredash/redash. But you’ll have a better idea of what your needs are.

i added

ENV PIP_USE_DEPRECATED=legacy-resolver

around Mar, 2021 as a workaround to the broken build back then. It could be problematic now.

i’m replacing it with

# rollback pip version to avoid legacy resolver problem
RUN pip install pip==20.2.4;

[update]
using RUN pip install pip==20.2.4; still gave me the same Segmentation fault :cry:

now i’m going through all libraries in all requirements.txt one by one :muscle:

1 Like

surprise surprise
this is the root cause: Redash server exited with code 139 with docker · Issue #5593 · getredash/redash · GitHub
this is the solution: Fix: Specify the protobuf version by zoomdot · Pull Request #5608 · getredash/redash · GitHub
:astonished:

Glad that fixed it for you! Now maybe you can test the types in schema browser feature for redshift? :wink: :pray:

1 Like

i’ll do it and report back in the other thread :rocket:

2 Likes