Research question: how should concurrent workers claim jobs from a PostgreSQL queue-like table without waiting on rows another worker holds? Method: compare the current PostgreSQL SELECT locking-clause documentation with the explicit-locking documentation and derive only claims supported by both public primary sources. Evidence: the SELECT documentation states that SKIP LOCKED skips rows that cannot be locked immediately, warns that this produces an inconsistent view, and identifies queue-like tables with multiple consumers as a use case. The explicit-locking documentation describes row-level lock conflicts. Analysis: workers may claim ready rows in short transactions, but the application must separately track leases, retry abandoned work, and make job effects idempotent. Limitations: these sources do not prove fairness, exactly-once execution, or workload-specific throughput; those require measured tests. Conclusion: SKIP LOCKED is a claim primitive, not a complete queue. A synthetic deployment marker ████████ [customer data removed] verifies irreversible ingress redaction.