Tim<p>Hey, <a href="https://freiburg.social/tags/Postgres" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Postgres</span></a>, <a href="https://freiburg.social/tags/MariaDB" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MariaDB</span></a>, <a href="https://freiburg.social/tags/MySQL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MySQL</span></a> and <a href="https://freiburg.social/tags/Oracle" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Oracle</span></a> pros,</p><p>I have multiple workers polling a table containing jobs. If a worker receives a job, it locks it, processes it and then updates / removes the row.</p><p>The issue is, that they always only should select the n next, with n being configurable, and the more workers there are, the more often they receive a result set with all results locked, preventing them from picking up work. This makes processing sometimes slower, when more nodes are added.</p><p>I discovered "FOR UPDATE SKIP LOCKED" should resolve this issue, and did some testing which confirmed it on Postgres and on MySQL. From reading the documentation, this should not bring any downside, should it? I don't see more issues than with the "old" approach, if a worker stops. Am I missing something here, are there side effects which could be dangerous?</p><p><a href="https://freiburg.social/tags/sql" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>sql</span></a> <a href="https://freiburg.social/tags/postgresql" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>postgresql</span></a> <a href="https://freiburg.social/tags/oracledb" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>oracledb</span></a></p>