fix: evtrigs ownership

[steve-chavez]

Fixes #1437 (comment).

Moves migrations/db/init-scripts to migrations/db/migrations.

[samrose]

@steve-chavez left a couple of comments, but looks good overall + thanks for tackling this.

@staaldraad might be worth reviewing this from security perspective in case you see some issue we don't here.

[samrose]

@steve-chavez I guess the other review point on this PR is that we should definitely run through thorough testing in a local infra context to make sure everything works as expected. I'll follow up with you directly on it.

[nthtrung09it]

hi @steve-chavez, @samrose, I want to ask if this MR breaks the self-hosted version.
In the self-hosted version, there are scripts mounted into the init-scripts folder.

https://github.com/supabase/supabase/blob/884743ac306461b2ac6389bbf15e963679d911c4/docker/docker-compose.yml#L392

And there is a 00-schema.sql which copied in ansible playbook, located inside Dockerfile-15 and Dockerfile-orioledb-17 files.

[samrose]

hi @steve-chavez, @samrose, I want to ask if this MR breaks the self-hosted version. In the self-hosted version, there are scripts mounted into the init-scripts folder.

https://github.com/supabase/supabase/blob/884743ac306461b2ac6389bbf15e963679d911c4/docker/docker-compose.yml#L392

And there is a 00-schema.sql which copied in ansible playbook, located inside Dockerfile-15 and Dockerfile-orioledb-17 files.

Hi @nthtrung09it folks who self host need some form of self-created upgrade support. We don't provide self-hosted upgrade support across our versions, and don't have it on our roadmap. So it is up to people who self host to create a pathway to migrate between versions.

We do open source the fundamentals of our own upgrade path. You may be able to adapt those to your approach, and they are found here https://github.com/supabase/postgres/tree/develop/ansible/files/admin_api_scripts/pg_upgrade_scripts the tool being used is pg_upgrade between instances example https://github.com/supabase/postgres/blob/develop/ansible/files/admin_api_scripts/pg_upgrade_scripts/initiate.sh#L406 but it's worth looking at the whole implementation

[samrose]

hi @steve-chavez, @samrose, I want to ask if this MR breaks the self-hosted version. In the self-hosted version, there are scripts mounted into the init-scripts folder.
https://github.com/supabase/supabase/blob/884743ac306461b2ac6389bbf15e963679d911c4/docker/docker-compose.yml#L392
And there is a 00-schema.sql which copied in ansible playbook, located inside Dockerfile-15 and Dockerfile-orioledb-17 files.

Hi @nthtrung09it folks who self host need some form of self-created upgrade support. We don't provide self-hosted upgrade support across our versions, and don't have it on our roadmap. So it is up to people who self host to create a pathway to migrate between versions.

We do open source the fundamentals of our own upgrade path. You may be able to adapt those to your approach, and they are found here https://github.com/supabase/postgres/tree/develop/ansible/files/admin_api_scripts/pg_upgrade_scripts the tool being used is pg_upgrade between instances example https://github.com/supabase/postgres/blob/develop/ansible/files/admin_api_scripts/pg_upgrade_scripts/initiate.sh#L406 but it's worth looking at the whole implementation

If you question is just about making the docker-compose.yml file in supabase/supabase work with these changes, we can update Dockerfiles and docker-compose.yml files sure. We just don't provide tooling for self-hosted upgrading, but we can update Dockerfile and compose files so that they will work

[nthtrung09it]

@samrose Yes, it's very cool to update Dockerfile and compose files for the self-hosted version. As I mentioned above, there are 3 files (98-webhooks.sql, 99-roles.sql, 99-jwt.sql) in docker-compose.yml in supabase/supabase and 1 file (00-schema.sql) in the Dockerfile.

[samrose]

@samrose Yes, it's very cool to update Dockerfile and compose files for the self-hosted version. As I mentioned above, there are 3 files (98-webhooks.sql, 99-roles.sql, 99-jwt.sql) in docker-compose.yml in supabase/supabase and 1 file (00-schema.sql) in the Dockerfile.

We'll take a look thanks @nthtrung09it

[steve-chavez]

Previously the pgtap tests on

postgres/migrations/tests/database/privs.sql

Lines 11 to 19 in 2db5569

	set role postgres;
	create table test_priv();
	SELECT table_owner_is('test_priv', 'postgres');
	SELECT table_privs_are('test_priv', 'supabase_admin', array['DELETE', 'INSERT', 'REFERENCES', 'SELECT', 'TRIGGER', 'TRUNCATE', 'UPDATE']);
	SELECT table_privs_are('test_priv', 'postgres', array['DELETE', 'INSERT', 'REFERENCES', 'SELECT', 'TRIGGER', 'TRUNCATE', 'UPDATE']);
	SELECT table_privs_are('test_priv', 'anon', array['DELETE', 'INSERT', 'REFERENCES', 'SELECT', 'TRIGGER', 'TRUNCATE', 'UPDATE']);
	SELECT table_privs_are('test_priv', 'authenticated', array['DELETE', 'INSERT', 'REFERENCES', 'SELECT', 'TRIGGER', 'TRUNCATE', 'UPDATE']);
	SELECT table_privs_are('test_priv', 'service_role', array['DELETE', 'INSERT', 'REFERENCES', 'SELECT', 'TRIGGER', 'TRUNCATE', 'UPDATE']);
	reset role;

Hid the reason of the failure, which was uncovered thanks to #1496:

default_privs.out       2025-03-26 01:15:37.820796798 +0000
2025-03-26T01:15:39.6288966Z postgres> @@ -5,8 +5,5 @@
2025-03-26T01:15:39.6289239Z postgres>   supabase_admin | public          | S
2025-03-26T01:15:39.6289567Z postgres>   supabase_admin | public          | f
2025-03-26T01:15:39.6290033Z postgres>   supabase_admin | public          | r
2025-03-26T01:15:39.6290355Z postgres> - postgres       | public          | S
2025-03-26T01:15:39.6290660Z postgres> - postgres       | public          | f
2025-03-26T01:15:39.6290965Z postgres> - postgres       | public          | r
2025-03-26T01:15:39.6291242Z postgres> -(6 rows)
2025-03-26T01:15:39.6291446Z postgres> +(3 rows)

See ci logs.

This means that the ALTER DEFAULT PRIVILEGES needs to run under supabase_admin and postgres, the latter is missing now.

[steve-chavez]

hi @steve-chavez, @samrose, I want to ask if this MR breaks the self-hosted version.

@nthtrung09it It doesn't look like it does. Those init-scripts references come from a folder that's created inside the Dockerfile, they don't come from the source directory.

The migrations should be preserved given the following:

postgres/Dockerfile-15

Line 190 in 2db5569

COPY migrations/db /docker-entrypoint-initdb.d/

postgres/Dockerfile-orioledb-17

Line 199 in 2db5569

COPY migrations/db /docker-entrypoint-initdb.d/

That being said, ideally we should build the Dockerfile directly from Nix, so tests passing would ensure the docker image builds.

[steve-chavez]

This was missing before, now it's much cleaner and explicit.

[steve-chavez]

Moving this after the regression tests, which offer better error reporting.

[samrose]

I wonder if there is a way to test that these ownerships won't regress toward the end of the AMI build too? That kind of testing has proven valuable over time/worth covering usually.

[samrose]

I think you covered this now