govulncheck analyzes symbol usage and only warns if your code reaches the affected symbol(s).
I’m not sure about cargo audit specifically, but most other security advisories are package scoped and will warn if your code transitively references the package, regardless of which symbols your code uses.
No one forces you to install the pre-commit hook on your local checkout so what you're suggesting is universally the case. You're perfectly free to just run it manually or let it fail in CI or use `--no-verify` when committing to skip the hook if you install it.
Advisory locks aren’t all sunshine and rainbows. They can only be unlocked by the Postgres connection that acquired the lock. That means you need to track the connection, typically by dedicating a connection to the job that needs locking.
Here’s a good issue describing the tradeoffs between a lock table and advisory locks.
Do people use advisory locks as the actual locking mechanism? I've always used them to synchronize access to a flag on the target resource, so the advisory lock is only held long enough to query or update that resource as locked. The alternative seems, yes, incredibly brittle.
That's quite a strong claim. I disagree. Military leadership, like business leadership, is imperfect. Both vary based on individuals, the operating environment, and culture.
> is you need to track if you've closed the channel
There is where you can use a function that captures the channel and guarantees that no matter how many times it is called that it only closes the channel once.
I’m not sure about cargo audit specifically, but most other security advisories are package scoped and will warn if your code transitively references the package, regardless of which symbols your code uses.
reply