> My original intention was to have the queue as a circular buffer where
> the size of the entries was variable, but possibly bounded. Certainly
> using fixed length records of large size seems somewhat wasteful.
>
Maybe we should do away with 'spill to disk' all together and either
hard-code an overflow behavior or make it a knob. Possible overflow
behaviors could be block until space is available, throw an error or
silently drop it.
Can the size of the shared memory segment for notifications be
configurable? That would allow those with large payloads or a huge
number of notifications to bump memory to avoid overflow cases. By
removing the disk and making shmem usage configurable, I think the
notify system would be flexible and could scale nicely.
Another added benefit is the payload limit can be much higher than
previously considered, because memory/performance concerns are now in
the hands of the DBA.
> Incidentally, I'd like to thank Joachim personally for having done this
> work,
+1
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/