Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified

On Tue, Oct 25, 2011 at 11:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Even given your recent changes to reduce the overhead of checking for
> sinval messages, I'm not sure that it'd be practical to move the sinval
> message processing to just-before-we-look-up-a-cache-entry.

Wait a minute: I'm confused. What's at issue here, at least AIUI, is
taking a TOAST pointer and fetching the corresponding value. But that
must involve reading from the TOAST table, and our usual paradigm for
reading from system catalogs is (1) take AccessShareLock, (2) read the
relevant rows, (3) release AccessShareLock. If we're doing that here,
then AcceptInvalidationMessages() is already getting called. If we're
not, this seems horribly unsafe; aside from the current bug, somebody
could rewrite the table in the interim.

> Right now,
> we do AcceptInvalidationMessages basically once per table per query
> (or maybe it's twice or so, but anyway a very small multiplier on that).
> If we try to do it every time through SearchSysCache, we are probably
> talking two to three orders of magnitude more checks, which ISTM is
> certain to push the sinval queue back up to the top of the heap for
> contention.

I think we've pretty much got the *contention* licked, barring an
increase in the number of things that generate sinval messages, but
calling it too often will still be slow, of course.

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