Andrew Chernow writes:
> I mentioned this up thread. I completely agree that overflow behavior should
> be
> tunable.
There is only one correct overflow behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Josh Berkus writes:
> (4) drop *old* notifications if the queue is full.
> Since everyone has made the point that LISTEN is not meant to be a full
> queueing system, I have no problem dropping notifications LRU-style.
NO, NO, NO, a thousand times no!
That turns NOTIFY into an unreliable signali
Joachim Wieland writes:
> The sequence in CommitTransaction() is like that:
> 1) add notifications to queue
> 2) commit to clog
> 3) signal backends
> Only those backends are signalled that listen to at least one channel,
> if the notify system isn't in use, then nobody will ever be signalled
>
We should probably also log the fact that we ran out of room, so that
the DBA knows that they ahve a design issue.
Can't they just bump allowed memory and avoid a redesign?
Alternately, it would be great to have a configuration option which
would allow the DBA to choose any of 3 behaviors vi
On 11/16/09 3:19 AM, Joachim Wieland wrote:
> 1) drop new notifications if the queue is full (silently or with rollback)
> 2) block until readers catch up (what if the backend that tries to write the
> notifications actually is the "lazy" reader that everybody is waiting for
> to
> proce
That is, if the queue overflows what you should do is drop the
payloads and condense all the messages for a given class into a single
notification for that class with "unknown payload". That way if a
cache which wants to invalidate specific objects gets a queue overflow
condition then at least it
On Thu, Nov 19, 2009 at 1:48 AM, Tom Lane wrote:
> Joachim Wieland writes:
>> 4) Allow readers to read uncommitted notifications as well.
>
> The question that strikes me here is one of timing --- apparently,
> readers will now have to check the queue *without* having received
> a signal? That c
On Mon, Nov 16, 2009 at 2:35 PM, Andrew Chernow wrote:
>
>>> 1) drop new notifications if the queue is full (silently or with
>>> rollback)
>>
>> I like this one best, but not with silence of course. While it's not the
>> most
>> polite thing to do, this is for a super extreme edge case. I'd rathe
Joachim Wieland writes:
> 4) Allow readers to read uncommitted notifications as well.
The question that strikes me here is one of timing --- apparently,
readers will now have to check the queue *without* having received
a signal? That could amount to an unpleasant amount of extra overhead
when t
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
We still need to decide what to do with queue full situations in
the proposed listen/notify implementation. I have a new ve
On Mon, Nov 16, 2009 at 9:05 AM, Greg Sabino Mullane >> We still need
to decide what to do with queue full situations in
>> the proposed listen/notify implementation. I have a new version
>> of the patch to allow for a variable payload size. However, the
>> whole notification must fit into one page
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> We still need to decide what to do with queue full situations in
> the proposed listen/notify implementation. I have a new version
> of the patch t
We still need to decide what to do with queue full situations in the proposed
listen/notify implementation. I have a new version of the patch to allow for a
variable payload size. However, the whole notification must fit into one page so
the payload needs to be less than 8K.
I have also added the
101 - 113 of 113 matches
Mail list logo
