This makes it so that channel names for NOTIFY/LISTEN/UNLISTEN are
consistent. That is that they are double quoted in all instances except
for when they are referenced by `pg_notify`. This way the channel names
are no longer case-insensitive.
This happens because of how PostgreSQL parses the SQL statements for
NOTIFY/LISTEN/UNLISTEN and treats the arguments as an identifier. Where
as it treats the arguments to `pg_notify` as only a string. This causes
arguments that are not double quoted to be adjusted to lower case when
passed to the SQL statement.
By making all usages consistent, we no longer have to worry about
channel names being odd.
When the queue name is uppercase, the listener will never receive the
notification when the job is enqueued. This is done specifically with
the enqueuer and consumer being separate neoq instances (server A kicks
off a job, server B is listening to perform the work).
I want to be able to know what job a log message is in regards to, so
this adds the queue to all of the log messages where its available. It
also makes some of the `error` logs more consistent with each other.
Since these values are being written in a separate go routine, it is
possible for a datarace to happen since we are reading them
unatomically. This just makes it so that both the reads ands writes are
done atomically.
Resolves#76
Previously, new, non-future jobs were announced by executing `NOTIFY` in
Go code. Triggers are much better suited for this, and reduces neoq
complexity by allowing PG to perform notification work for most jobs.
"Future" jobs continue to use the `announceJob` method on a timer.
This test is to provide a minimal proof that jobs can be consumed by
multiple workers and in a way can only be consumed once. If the
execCount does not match the expected count then this test will fail
because either too many jobs were executed (like one executing twice) or
a job was dropped when it should not have been.
This reverts commit bc8df98894.
This commit was totally wrong about the motivations for holding transactions throught the duration of jobs.
Ths is an embarrassing mistake because it is the crux of the entire Postgres backend. Transactions must be held while jobs are being processed because `FOR UPDATE` requires the transaction that issued the `SELECT * FOR UPDATE ...` query to remain open to hold the lock (https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS)
The reverted commit allowed jobs to be picked up by multiple workers.
`cancelFuncs` in the pg backend was intended for gracefully shutting down the backend with Shutdown(). Adding a
new cancel function every time a job is added to a queue isn't of any use, because there is nothing to "cancel" by
cancelling the context unless a job is in progress.
This was effectively a memory leak.
