Re: Support for REINDEX CONCURRENTLY

On Mon, Sep 16, 2013 at 10:38 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-08-29 10:39:09 -0400, Robert Haas wrote:
>> I have been of the opinion for some time now that the
>> shared-invalidation code is not a particularly good design for much of
>> what we need.  Waiting for an old snapshot is often a proxy for
>> waiting long enough that we can be sure every other backend will
>> process the shared-invalidation message before it next uses any of the
>> cached data that will be invalidated by that message.  However, it
>> would be better to be able to send invalidation messages in some way
>> that causes them to processed more eagerly by other backends, and that
>> provides some more specific feedback on whether or not they have
>> actually been processed.  Then we could send the invalidation
>> messages, wait just until everyone confirms that they have been seen,
>> which should hopefully happen quickly, and then proceed.
>
> Actually, the shared inval code already has that knowledge, doesn't it?
> ISTM all we'd need is have a "sequence number" of SI entries which has
> to be queryable. Then one can simply wait till all backends have
> consumed up to that id which we keep track of the furthest back backend
> in shmem.

In theory, yes, but in practice, there are a few difficulties.

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.

2. Every time we add a new kind of sinval message, we increase the
frequency of sinval resets, and those are bad.  So any notifications
that we choose to send this way had better be pretty low-volume.

Considering the foregoing points, it's unclear to me whether we should
try to improve sinval incrementally or replace it with something
completely new.  I'm sure that the above-mentioned problems are
solvable, but I'm not sure how hairy it will be.  On the other hand,
designing something new could be pretty hairy, too.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company