Live data from Hacker News

What is ‘skip locked’ for in PostgreSQL 9.5? (2016)

blog.2ndquadrant.com

81–82 of 82 posts

Re: What is ‘skip locked’ for in PostgreSQL 9.5? (2016)

#81
post #72
post #67

Earlier quoted context omitted.

You're making a lot of assumptions that aren't terribly valid for most use cases. Not to say that strict consistency requirements don't exist, they certainly do, but they are the exception rather than the norm. A one person startup doesn't usually care too much about losing a bit of client data. > If you have a full-time ops staff, throwing another marginal piece of infrastructure on the pile isn't much of an issue.…

It's nothing like insulting. Think of it like absolute and marginal costs. You have absolute infrastructure -- the sum total of all your infrastructure -- and you have marginal infrastructure -- bits and pieces that can be added and removed. If you have no Redis and then you have Redis, NewAbsoluteInfrastructure = OldAbsoluteInfrastructure + Redis, and Redis is your marginal infrastructure.

I mis-interpreted your use of 'marginal', sorry about that.

Re: What is ‘skip locked’ for in PostgreSQL 9.5? (2016)

#82
Locking the task row and doing the work in the same transaction has the nice property, that the task will be available again, if the worker fails and the transaction is rolled back.

Unfortunately this may cause problems when the tasks take considerable time to complete and long running transactions are the result: "Postgres Job Queues & Failure By MVCC" https://brandur.org/postgres-queues

Post reply on HN