Re: curious regression failures

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> But given Tom's comments this commit stands out too:

> From: "Alvaro Herrera" <alvherre(at)postgresql(dot)org>
> Log Message:
> -----------
> Release the exclusive lock on the table early after truncating it in lazy
> vacuum, instead of waiting till commit.

I had thought about that one and not seen a problem with it --- but
sometimes when the light goes on, it's just blinding :-(. This change
is undoubtedly what's breaking it. The failures in question are coming
from commands that try to insert new entries into various system tables.
Now normally, the first place a backend will try to insert a brand-new
tuple in a table is the rd_targblock block that is remembered in
relcache as being where we last successfully inserted. The failures
must be happening because autovacuum has just truncated away where
rd_targblock points. There is a mechanism to reset everyone's
rd_targblock after a truncation: it's done by broadcasting a
shared-invalidation relcache inval message for that relation. Which
happens at commit, before releasing locks, which is the correct time for
the typical application of this mechanism, namely to make sure people
see system-catalog updates on time. Releasing the exclusive lock early
allows backends to try to access the relation again before they've heard
about the truncation.

There might be another way to manage this, but we're not inventing
a new invalidation mechanism for 8.3. This patch will have to be
reverted for the time being :-(

regards, tom lane