On 17 October 2012 11:26, Hannu Krosing <hannu@2ndquadrant.com> wrote:
> LOGGED ONLY TABLE is very technical description of realisation - I'd
> prefer it to work as mush like a table as possible, similar to how VIEW
> currently works - for all usages that make sense, you can simply
> substitute it for a TABLE
>
> QUEUE emphasizes the aspect of logged only table that it accepts
> "records" in a certain order, persists these and then quarantees
> that they can be read out in exact the same order - all this being
> guaranteed by existing WAL mechanisms.
>
> It is not meant to be a full implementation of application level queuing
> system though but just the capture, persisting and distribution parts
>
> Using this as an "application level queue" needs a set of interface
> functions to extract the events and also to keep track of the processed
> events. As there is no general consensus what these shoul be (like if
> processing same event twice is allowed) this part is left for specific
> queue consumer implementations.
The two halves of the queue are the TAIL/entry point and the HEAD/exit
point. As you point out these could be on the different servers,
wherever the logical changes flow to, but could also be on the same
server. When the head and tail are on the same server, the MESSAGE
QUEUE syntax seems appropriate, but I agree that calling it that when
its just a head or just a tail seems slightly misleading.
I guess the question is whether we provide a full implementation or
just the first half.
We do, I think, want a full queue implementation in core. We also want
to allow other queue implementations to interface with Postgres, so we
probably want to allow "first half" only as well. Meaning we want both
head and tail separately in core code. The question is whether we
require both head and tail in core before we allow commit, to which I
would say I think adding the tail first is OK, and adding the head
later when we know exactly the design.
Having said that, the LOGGING ONLY syntax makes me shiver. Better name?
I should also add that this is an switchable sync/asynchronous
transactional queue, whereas LISTEN/NOTIFY is a synchronous
transactional queue.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
