NOTIFY docs fixup - emit and deliver consistency
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t43018psql -h localhost -U postgresBuilt from patchset v4 (message #4), September 20, 2026 at 12:03 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t43018_4 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t43018_4 && git checkout t43018_4Patchset v4 (message #4) is on t43018_4
Hackers,
Over in [1]/messages/by-id/6EDB6A52-17F1-4DA9-B5B8-3BFFD5A576C8@loblaw.ca Greg got confused by some wording in our NOTIFY documentation.
The attached patch uses "emits" and "delivered" more consistently (in
lieu of "processed" in the complained of location).
[1]: /messages/by-id/6EDB6A52-17F1-4DA9-B5B8-3BFFD5A576C8@loblaw.ca
/messages/by-id/6EDB6A52-17F1-4DA9-B5B8-3BFFD5A576C8@loblaw.ca
David J.
Attachments:
v1-notify-doc-fixup.patchapplication/octet-stream; name=v1-notify-doc-fixup.patchDownload+3-3
"David G. Johnston" <david.g.johnston@gmail.com> writes:
Over in [1] Greg got confused by some wording in our NOTIFY documentation.
The attached patch uses "emits" and "delivered" more consistently (in
lieu of "processed" in the complained of location).
Meh --- I do not think "emitted" is much of an improvement over "sent".
(I agree it's not great that these two places don't use matching
terminology, though.) Neither is clear as to where the message is
sent or emitted.
As for the other end of it, I don't like "delivered" because it presumes
that the processing action necessarily is to send the message to the
connected client. When a backend takes a message off the queue, it may
just drop it on the floor because its client is not listening to that
channel. Nonetheless, until it's done so that message must consume
queue space.
Maybe we could use terminology along the lines of "added to the
queue" and "removed from the queue"?
regards, tom lane
On Tue, Sep 29, 2020 at 7:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Maybe we could use terminology along the lines of "added to the
queue" and "removed from the queue"?
Quickly looking it over with this in mind there are a few spots that can be
cleaned up and linked together by explicitly talking about a FIFO queue as
the mechanism instead of the less precise send/process/deliver. A bit more
invasive but I think it will be done more clearly with this approach.
David J.
On Tue, Sep 29, 2020 at 8:38 PM David G. Johnston <
david.g.johnston@gmail.com> wrote:
On Tue, Sep 29, 2020 at 7:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Maybe we could use terminology along the lines of "added to the
queue" and "removed from the queue"?Quickly looking it over with this in mind there are a few spots that can
be cleaned up and linked together by explicitly talking about a FIFO queue
as the mechanism instead of the less precise send/process/deliver. A bit
more invasive but I think it will be done more clearly with this approach.
As attached.