I was looking at the migration locking implementation and noticed that pg_try_advisory_lock is used to acquire the migration lock.
Is there a specific reason for choosing pg_try_advisory_lock over pg_advisory_lock?
In our setup, multiple independent microservices share the same PostgreSQL database. Each service is built and deployed independently, so it is possible for several instances to start concurrently and attempt to run migrations at roughly the same time.
Because pg_try_advisory_lock is non-blocking, one service acquires the lock while the others immediately fail when they receive false. This means deployments can fail simply because another service is currently running migrations.
Would it make more sense to use pg_advisory_lock instead? That would cause competing migration processes to wait until the existing migration completes and releases the lock, rather than failing immediately.
I'm wondering if there are any downsides or design considerations that led to the current approach. It seems that a blocking lock would provide a smoother experience for environments where multiple services share the same database and may start concurrently.
I was looking at the migration locking implementation and noticed that pg_try_advisory_lock is used to acquire the migration lock.
Is there a specific reason for choosing pg_try_advisory_lock over pg_advisory_lock?
In our setup, multiple independent microservices share the same PostgreSQL database. Each service is built and deployed independently, so it is possible for several instances to start concurrently and attempt to run migrations at roughly the same time.
Because pg_try_advisory_lock is non-blocking, one service acquires the lock while the others immediately fail when they receive false. This means deployments can fail simply because another service is currently running migrations.
Would it make more sense to use pg_advisory_lock instead? That would cause competing migration processes to wait until the existing migration completes and releases the lock, rather than failing immediately.
I'm wondering if there are any downsides or design considerations that led to the current approach. It seems that a blocking lock would provide a smoother experience for environments where multiple services share the same database and may start concurrently.