Previously pg backend would hold connections/transactions during the
execution of job handlers. So, e.g. if a job ran for 30 seconds, a
transaction and its connection would be held for the entirety of those
30 seconds.
The reason it was originally implemented this way is because originally
the vision was to pass every job a `tx` that could be used throughout
the job. If the job failed, its `tx` would be rolled back in neoq
so that user would not have to handle rollbacks and connection handling
themselves, were they to perform database operations in their jobs.
But ultimately, that is a lot of hand-holding at the cost of a lot of
resources, for a use case that is both unlikely and does not work as
soon as the user's application and neoq tables are in different
databases.
This commit reverses that poor decision and opts to improve performance
over giving users an ergonomic transaction handling API.
Previously, neoq would query to see if new jobs' (fingerprint, status)
tuple were unique. This change adds a unique index on (fingerprint,
status) and simply allows unique key constraint violations to be
returned from `Enqueue` instead. This prevents one additional query
for every new queue item.
Packages `pq` and `pgx` allow different connection string parameters.
Since `pgx` is neoq's primary SQL library, but migrations use `pq`,
we had to ensure that pgx connection parameters do not get passed to
the pq library when running migrations.
This issue was introduced in version `0.20.0`.
