A workshop website can avoid duplicate processing and still invite the wrong person from its waitlist. Database locking answers which worker may act; the business must separately approve eligibility, priority and how long an invitation lasts. Commission a decision log before automatic promotion.
Primary evidence and claim boundaries
PostgreSQL18 documents that SKIP LOCKED skips rows that cannot be locked immediately and can be useful for queue-like tables. It produces an inconsistent view and does not by itself establish business fairness or FIFO selection. Primary reference · Read 18 October 2026.
Filled acceptance example
Original synthetic teaching scenario, not a client case, provider integration test or business result. The example policy needs the actual owner’s approval; scroll the table on narrow screens.
| Input and state | Declared check | Expected output and decision |
|---|---|---|
| One place; W1 joined09:00, eligible, opted in | Declared policy: oldest eligible first | Propose invitation to W1; not a confirmed booking |
| W2 joined09:01; W1 temporarily worker-locked | Worker uses SKIP LOCKED | May observe W2; do not claim strict FIFO fairness |
| W1 invitation expiry10:00; now10:00 | This policy uses half-open validity | Invitation expired; resolve before another promise |
| W3 earliest but consent withdrawn | Eligibility includes current permission | Exclude W3 without contacting them |
Practical handover procedure
- Write the merchant-approved eligibility and priority rules, including withdrawn requests, ties and invitation expiry. Keep waitlist entry, invitation and confirmed booking separate.
- Replay the four records with a fixed test clock and two simulated workers. Require a log that explains why a person was selected or skipped.
- Ask the implementer to demonstrate atomic capacity and invitation updates in an authorised test database. A sequential teaching log cannot prove concurrent correctness.
Interpret the outcome
The first row approves only a proposed invitation. The locked-row example exposes a trade-off between worker throughput and strict business ordering. A system promising FIFO must demonstrate that policy explicitly, rather than cite a database option as its fairness evidence.
Acceptance decision
Require explainable selection, no contact after withdrawal and no duplicate capacity promise under the approved concurrency tests.
Limits and unverified work
Synthetic people IDs and timing only. No attendee data, messages, real database queries, invitation or booking are created. This is not a complete scheduling engine.
Download the filled bilingual acceptance record — Contains the inputs, steps, expectations and limits. This is a teaching record, not an executable production integration.