Excerpts from Markus Wanner's message of mar jul 20 14:54:42 -0400 2010: > > With respect to imessages specifically, what is the motivation for > > using shared memory rather than something like an SLRU? The new > > LISTEN implementation uses an SLRU and handles variable-size messages, > > so it seems like it might be well-suited to this task. > > Well, imessages predates the new LISTEN implementation by some moons. > They are intended to replace (unix-ish) pipes between processes. I fail > to see the immediate link between (S)LRU and inter-process message > passing. It might be more useful for multiple LISTENers, but I bet it > has slightly different semantics than imessages.
I guess what Robert is saying is that you don't need shmem to pass messages around. The new LISTEN implementation was just an example. imessages aren't supposed to use it directly. Rather, the idea is to store the messages in a new SLRU area. Thus you don't need to mess with dynamically allocating shmem at all. > But to be honest, I don't know too much about the new LISTEN > implementation. Do you think a loss-less > (single)-process-to-(single)-process message passing system could be > built on top of it? I don't think you should build on top of LISTEN but of slru.c. This is probably more similar to multixact (see multixact.c) than to the new LISTEN implementation. I think it should be rather straightforward. There would be a unique append-point; each process desiring to send a new message to another backend would add a new message at that point. There would be one read pointer per backend, and it would be advanced as messages are consumed. Old segments could be trimmed as backends advance their read pointer, similar to how sinval queue is handled. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
