You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running supabase db pull (with or without the --schema flag) after enabling pgmq and creating queues results in unstable migration files. There appear to be a few bugs going on:
Statements like grant select on table "pgmq"."a_queue_name" to "pg_monitor"; are run on tables that don't yet exist. The migration file never creates the table, it must be copied from the schema definition.
Error: ERROR: relation "pgmq.a_queue_name" does not exist (SQLSTATE 42P01) At statement 6: grant select on table "pgmq"."a_queue_name" to "pg_monitor"
Migration statements that attempt to create system default types for pgmq result in "already created" errors:
Statement: create type "pgmq"."message_record" as ("msg_id" bigint, "read_ct" integer, "enqueued_at" timestamp with time zone, "vt" timestamp with time zone, "message" jsonb); result in
Error: ERROR: type "message_record" already exists (SQLSTATE 42710)
I worked around the above bugs by patching the generated migration file with the table definition (e.g., create table pgmq.q_queue_name), which allows my local database to be rebuilt successfully. However, subsequent runs of supabase db pull --schema public,pgmq,pgmq_public results in a new migration file, dropping all queue tables:
altertable"pgmq"."a_queue_name" drop constraint"a_queue_name_pkey";
altertable"pgmq"."q_queue_name" drop constraint"q_queue_name_pkey";
dropindex if exists "pgmq"."a_queue_name_pkey";
dropindex if exists "pgmq"."archived_at_idx_queue_name";
dropindex if exists "pgmq"."q_queue_name_pkey";
dropindex if exists "pgmq"."q_queue_name_vt_idx";
droptable"pgmq"."a_queue_name";
droptable"pgmq"."q_queue_name";
To Reproduce
Enable queues through integration in supabase studio
Turn on Expose Queues via PostgREST setting
Create a basic queue
Run supabase db pull. The migration file that's created performs commands on tables that don't exist yet, and create types that already exist (from enabling pgmq).
Patch the generated migration file by copying the table definition from the Studio
Run supabase db pull again: The queue tables are dropped in a newly generated migration file.
Expected behavior
Stable and consistent migration files to manage pgmq
Screenshots
If applicable, add screenshots to help explain your problem.
System information
OS: MacOS
Version of supabase-js: 2.2.1
Version of Node.js: v20.17.0
The text was updated successfully, but these errors were encountered:
Bug report
Describe the bug
Running
supabase db pull
(with or without the--schema
flag) after enabling pgmq and creating queues results in unstable migration files. There appear to be a few bugs going on:grant select on table "pgmq"."a_queue_name" to "pg_monitor";
are run on tables that don't yet exist. The migration file never creates the table, it must be copied from the schema definition.ERROR: relation "pgmq.a_queue_name" does not exist (SQLSTATE 42P01) At statement 6: grant select on table "pgmq"."a_queue_name" to "pg_monitor"
create type "pgmq"."message_record" as ("msg_id" bigint, "read_ct" integer, "enqueued_at" timestamp with time zone, "vt" timestamp with time zone, "message" jsonb);
result inERROR: type "message_record" already exists (SQLSTATE 42710)
create table pgmq.q_queue_name
), which allows my local database to be rebuilt successfully. However, subsequent runs ofsupabase db pull --schema public,pgmq,pgmq_public
results in a new migration file, dropping all queue tables:To Reproduce
Expose Queues via PostgREST
settingsupabase db pull
. The migration file that's created performs commands on tables that don't exist yet, and create types that already exist (from enabling pgmq).supabase db pull
again: The queue tables are dropped in a newly generated migration file.Expected behavior
Stable and consistent migration files to manage
pgmq
Screenshots
If applicable, add screenshots to help explain your problem.
System information
The text was updated successfully, but these errors were encountered: