Hacker News
new
|
past
|
comments
|
ask
|
show
|
jobs
|
submit
login
79 days ago
|
parent
|
context
|
favorite
| on:
Testing Postgres race conditions with synchronizat...
[dead]
lirbank
79 days ago
|
next
[–]
Nice - that's a good case for barriers too. When there's no row to SELECT FOR UPDATE against, you'd inject the barrier after acquiring the advisory lock and verify the second transaction blocks until the first commits.
klysm
79 days ago
|
prev
|
next
[–]
Seems like a good way to materialize the conflict.
deepsun
79 days ago
|
prev
[–]
I always did "INSERT ... ON CONFLICT DO NOTHING".
nurettin
79 days ago
|
parent
[–]
Does that queue when the table is locked? Or just skip writes entirely whenever there is a transaction?
deepsun
78 days ago
|
root
|
parent
[–]
Yes, unless you SET LOCAL lock_timeout = '1ms'; inside the transaction.
Guidelines
|
FAQ
|
Lists
|
API
|
Security
|
Legal
|
Apply to YC
|
Contact
Search: