From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Listen / Notify - what to do when the queue is full |
Date: | 2009-11-19 04:03:28 |
Message-ID: | 4B04C390.5040701@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Chernow <ac(at)esilo(dot)com> writes:
>> Tom Lane wrote:
>>> There is only one correct overflow behavior.
>
>> I count three.
>
> Waiting till you can insert is reasonable (especially if we have some
> behavior that nudges other backends to empty the queue). If by "skip"
> you mean losing the notify but still committing, that's incorrect.
> There is no room for debate about that.
Yeah like I said, skip felt weak.
In regards to waiting, what would happen if other backends couldn't help empty
the queue because they to are clogged? ISTM that any attempt to flush to other
non-disk queues is doomed to possible overflows as well. Then what?
Personally, I would just wait until room became available or the transaction was
canceled. We could get fancy and tack a timeout value onto the wait.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-19 04:12:33 | Re: Listen / Notify - what to do when the queue is full |
Previous Message | Andrew Dunstan | 2009-11-19 03:50:21 | Re: "Not safe to send CSV data" message |