On Tue, Sep 17, 2013 at 7:04 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
