Re: ALTER TABLE lock strength reduction patch is unsafe

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Mon, Dec 19, 2011 at 12:05:09PM -0500, Robert Haas wrote:
>> Yet another option, which I wonder whether we're dismissing too
>> lightly, is to just call GetSnapshotData() and do the scan using a
>> plain old MVCC snapshot. Sure, it's more expensive than SnapshotNow,
>> but is it expensive enough to worry about?

That might actually be workable ...

> I created a function that does this in a loop:

> HeapTuple t;

> CatalogCacheFlushCatalog(ProcedureRelationId);
> t = SearchSysCache1(PROCOID, ObjectIdGetDatum(42) /* int4in */);
> if (!HeapTupleIsValid(t))
> elog(ERROR, "cache lookup failed for function 42");
> ReleaseSysCache(t);

... but this performance test seems to me to be entirely misguided,
because it's testing a situation that isn't going to occur much in the
field, precisely because the syscache should prevent constant reloads of
the same syscache entry.

Poking around a bit, it looks to me like one of the bigger users of
non-cache-fronted SnapshotNow scans is dependency.c. So maybe testing
the speed of large cascaded drops would be a more relevant test case.
For instance, create a schema containing a few thousand functions, and
see how long it takes to drop the schema.

Another thing that would be useful to know is what effect such a change
would have on the time to run the regression tests with
CLOBBER_CACHE_ALWAYS. That has nothing to do with any real-world
performance concerns, but it would be good to see if we're going to
cause a problem for the long-suffering buildfarm member that does that.

regards, tom lane