"Andrew Dunstan" <andrew@dunslane.net> writes:
> Incidentally, I think we will also need to limit the length of the message
> string if we're going to store this in shared memory. I'm currently
> thinking of NAMEDATALEN per message, but I am open to argument.
I suppose you're envisioning a ring of fixed-size message buffers
similar to the sinval implementation. With two NAMEDATALEN items
per message this would be 128 bytes each, a lot of which would go unused
in typical applications ... but on the other hand I can foresee some
apps wishing they could send payload strings longer than NAMEDATALEN.
Seems like it would not be that much harder to allow variable-length
messages, remove the padding and avoid any hard limit on message size.
You'd have to track the "fill" and "empty" pointers at the level of
bytes not message numbers, but so what?
regards, tom lane