The direct answer
Use PostgreSQL notifications to prompt inspection of trusted job state, not as the authoritative job record. Commit listener registration before an initial inspection in a new transaction, then handle later hints without assuming one notification per job. Admission, current authorization, claiming and completed effects require separate evidence.
Choose a wake-up contract rather than inventing a queue
A support console accepts a notes-summary task and wants a background consumer to notice it. The useful question is not simply whether a signal arrived. It is whether the task was admitted, what state the consumer can currently inspect, and whether that state authorizes any next operation.
This original worksheet uses fictional job J-A, trusted registry G-A, consumer L-A and harmless wake label N-A on configured channel C-A. These are symbolic labels, not actual records or messages. The selected primary bodies identify PostgreSQL 18 documentation; no patch release, installed server or client driver was inspected. G-A’s permissions, supported storage configuration and admission contract remain separately reviewed prerequisites. This guide does not implement a queue, worker claim or retry service.
Keep producer commitment separate from the hint
Propose recording J-A and requesting N-A within one supported producer transaction. The transaction tutorial explains grouped changes, their visibility and rollback. It also warns that client libraries can supply transaction boundaries automatically. A real adapter must establish the actual boundary; two nearby calls are not proof of one transaction.
Record admission as confirmed only when the registry’s independently supported admission requirements are met. A tutorial’s persistence description does not inspect your storage settings, failover behavior or application acknowledgement. If the commit result is unknown, keep admission unknown; do not replace it with a friendly notification log.
NOTIFY defers transaction notifications until commit. Its pending-notification queue can cause notifying transactions to fail at commit if full. Thus “the row write was attempted” and “the application requested a wake-up” are not sufficient admission evidence. No queue-size configuration or monitoring API is selected here.
Establish registration before the initial inspection
LISTEN registration takes effect at commit. An earlier registry read can race concurrent producers. The documented order is:
- Establish L-A’s selected session registration and commit it.
- In a new transaction, inspect the currently permitted registry state under the application’s supported discovery rules.
- Then use notifications to prompt inspection for subsequent changes.
The same documentation notes that early notifications may refer to updates already seen during initial inspection. Record “already observed” rather than starting the task twice. That is a discovery decision, not an implementation of business-effect idempotency.
For the useful positive, assume G-A has supported committed admission for eligible J-A and L-A follows this sequence. Initial inspection can identify the permitted J-A record; a later N-A merely asks L-A to look again. The next stage remains a separate authorized decision. Nothing in this worksheet claims, runs or completes J-A.
Treat signal counts and contents as separate observations
Identical payloads on the same channel within one transaction fold into one notification; different transactions are not folded together. A listening session inside a transaction receives its client notification after that transaction ends. Notification timing rules therefore do not support counting wake-ups as jobs or diagnosing an absent client event as an empty registry.
Notifications are visible to all users; channel names enforce no table association. Use fixed minimized N-A, without prompt text, credentials or protected job details. Minimization does not authenticate work or establish confidential signaling.
Review eight inert discovery cases
| Invented condition | Truthful decision |
|---|---|
| N-A arrives, but no supported admission for J-A is found | Do not label J-A queued or execute it from the hint. |
| Eligible G-A work exists after L-A disconnects | Treat reconnect as fresh registration and initial inspection; do not assume historical hint replay. |
| L-A inspects before registration commits | Reject the claimed supported startup sequence; redo the design’s ordering, not an observed database operation. |
| Three eligible records share repeated identical hints in one producer transaction | One hint cannot establish one job. Inspect permitted registry state; do not infer a complete job count from the signal. |
| L-A remains inside a long transaction | A missing client event need not mean no producer commit. Separate listener progress from registry admission. |
| A payload proposes another workspace or model action | Use no proposed authority. Resolve only currently permitted registry objects. |
| Producer rollback, commit failure or unknown acknowledgement | Keep the supported failed or unknown admission state. Do not report success or repeat work automatically. |
| J-A is completed, already owned elsewhere or no longer authorized | Another hint creates no fresh claim. Follow the supported current disposition. |
Keep a compact review ledger with producer disposition, listener-registration phase, inspection disposition, hint observation and permitted next decision. An event received by a client and a record discovered by an authorized read are different evidence.
Make session loss and unimplemented recovery visible
LISTEN registrations belong to the session and clear when it ends; delivery targets current listeners. Session semantics supply no durable historical replay contract for a replacement session. A reconnect path must therefore include the documented registration-and-inspection sequence rather than wait for an old hint.
Client event handling, bounded periodic reconciliation, complete registry discovery, claim coordination and effect confirmation still need their own supported designs. None is supplied here. No no-lost-work, exactly-once, exclusive-consumer or universal durability result follows. The proposed initial inspection is not proof that every eligible record was enumerated.
For these proposed cases, no SQL, database connection, session, listener, channel, timer or model operation ran. Only documentation and private editorial files were read or written. Boundary is a prelaunch model router with planned request-path checks, not a shipped notification or queue service. The synthetic action exercise and existing mock evidence establish different, explicitly limited controls.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.