From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Notify enhancement |
Date: | 2006-12-04 14:05:22 |
Message-ID: | 45742B22.2000500@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Andrew Dunstan" <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2006-12-04 14:10:25 | Bundle of patches |
Previous Message | Oleg Bartunov | 2006-12-04 14:00:52 | GiN for 8.1 patch updated |