On Tue, Sep 17, 2013 at 7:04 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> 1. We're not in a huge hurry to ensure that sinval notifications are
>> delivered in a timely fashion. We know that sinval resets are bad, so
>> if a backend is getting close to needing a sinval reset, we kick it in
>> an attempt to get it to AcceptInvalidationMessages(). But if the
>> sinval queue isn't filling up, there's no upper bound on the amount of
>> time that can pass before a particular sinval is read. Therefore, the
>> amount of time that passes before an idle backend is forced to drain
>> the sinval queue can vary widely, from a fraction of a second to
>> minutes, hours, or days. So it's kind of unappealing to think about
>> making user-visible behavior dependent on how long it ends up taking.
>
> Well, when we're signalling it's certainly faster than waiting for the
> other's snapshot to vanish which can take ages for normal backends. And
> we can signal when we wait for consumption without too many
> problems.
> Also, I think in most of the usecases we can simply not wait for any of
> the idle backends, those don't use the old definition anyway.
Possibly. It would need some thought, though.
> I am pretty sure there's quite a bit to improve around sinvals but I
> think any replacement would look surprisingly similar to what we
> have. So I think doing it incrementally is more realistic.
> And I am certainly scared by the thought of having to replace it without
> breaking corner cases all over.
I guess I was more thinking that we might want some parallel mechanism
with somewhat different semantics. But that might be a bad idea
anyway. On the flip side, if I had any clear idea how to adapt the
current mechanism to suck less, I would have done it already.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company