Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
bstempi
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
4 ms
·
1.
▲
by
bstempi
3y ago
I think I see the difference. In my solution, the id I was passing to pg_try_advisory_lock was the id of the record that was being processed, which would allow several threads to acquire jobs in parallel. The second difference is that my so
2.
▲
by
bstempi
3y ago
> What did you do to avoid implicit locking, and what sort of isolation level were you using? I avoided implicit locking by manually handling transactions. The query that acquired the lock was a separate transaction from the query that f
3.
▲
by
bstempi
3y ago
Not the author, but I've used PG like this in the past. My criteria for selecting a job was (1) the job was not locked and (2) was not in a terminal state. If a job was in the "processing" state and the worker died, that lock
4.
▲
by
bstempi
3y ago
I've done something like this and opted to use advisory locks instead of row locks thinking that I'd increase performance by avoiding an actual lock. I'm curious to hear what the team thinks the pros/cons of a row vs adv