Tom Lane wrote:
> "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?
>
>
Ok. But I think the buffer size as a whole needs to be fixed, no? And if
so, we probably need some limit on message size to prevent "NOTIFY
some_event 'a really long string'; " from filling up the buffer in one hit.
I'm also trying to figure out what a reasonable default buffer size will
be. Thinking of the needs for which I will be providing (one listener,
small names/payloads), 256Kb or 512Kb would be ample, possibly even
excessive. But other users might have bigger needs.
cheers
andrew
