Re: Listen / Notify rewrite

On Thu, Nov 12, 2009 at 8:25 AM, Andrew Chernow <ac@esilo.com> wrote:
>
>>>> 2. The payload parameter is optional. A notifying client can either call
>>>> "NOTIFY foo;" or "NOTIFY foo 'payload';". The length of the payload is
>>>> currently limited to 128 characters... Not sure if we should allow
>>>> longer
>>>> payload strings...
>>>
>>> Might be a good idea to make the max the same as the max length for
>>> prepared transaction GUIDs?  Not sure anyone would be shipping those
>>> around, but it's a pre-existing limit of about the same size.
>>
>> Yes, sounds reasonable to have the same limit for user-defined
>> identifiers...
>>
>
> [..begging..] Can this be increased significantly?  I don't get it, is there
> any technical reason to make the limit soo small?  This drastically reduces
> the usefulness of the payload.  I've wanted this feature for quite sometime
> and it is quite disappointing that I could not even use it because it is
> unjustifiably limited.

+1

What advantage is there in limiting it to a tiny size?  This is a
'payload' after all...an arbitrary data block. Looking at the patch I
noticed the payload structure (AsyncQueueEntry) is fixed length and
designed to lay into QUEUE_PAGESIZE (set to) BLCKSZ sized pages.

Couple of questions:

*) is BLCKSZ a hard requirement, that is, coming from the slru
implementation, or can QUEUE_PAGESIZE be bumped independently of block
size.

*) why not make the AsyncQueueEntry divide evenly into BLCKSZ, that
is, make the whole structure a size that is a multiple of two?  (this
would make the payload length 'weird')

*) is there any downside you see to making the AsyncQueueEntry
structure exactly BLCKSZ bytes in size?  Are we worried about the
downsides of spinning the notifications out to disk?

*) Is a variable length AsyncQueueEntry possible? (presumably bounded
by the max page size).  Or does complicate the implementation too
much?

merlin





merlin