Thread: pgsql: Fix brain fade in DefineIndex(): it was continuing to access the

Log Message:
-----------
Fix brain fade in DefineIndex(): it was continuing to access the table's
relcache entry after having heap_close'd it.  This could lead to misbehavior
if a relcache flush wiped out the cache entry meanwhile.  In 8.2 there is a
very real risk of CREATE INDEX CONCURRENTLY using the wrong relid for locking
and waiting purposes.  I think the bug is only cosmetic in 8.0 and 8.1,
because their transgression is limited to using RelationGetRelationName(rel)
in an ereport message immediately after heap_close, and there's no way (except
with special debugging options) for a cache flush to occur in that interval.
Not quite sure that it's cosmetic in 7.4, but seems best to patch anyway.

Found by trying to run the regression tests with CLOBBER_CACHE_ALWAYS enabled.
Maybe we should try to do that on a regular basis --- it's awfully slow,
but perhaps some fast buildfarm machine could do it once in awhile.

Modified Files:
--------------
    pgsql/src/backend/commands:
        indexcmds.c (r1.161 -> r1.162)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/indexcmds.c?r1=1.161&r2=1.162)

[redirected to -hackers]

Tom Lane wrote:
> Found by trying to run the regression tests with CLOBBER_CACHE_ALWAYS enabled.
> Maybe we should try to do that on a regular basis --- it's awfully slow,
> but perhaps some fast buildfarm machine could do it once in awhile.
>
>
>

We currently don't have any way of providing for settings other than via
the configure script options. We could in theory make provision for
adding stuff to pg_config_manual.h, although it would be a bit more
difficult in the vpath (I guess for vpath we could just blow that file
away along with the files bison, flex etc. lob in the repo).

So the question is: is such a facility likely to be of value? It would
probably involve just a handful of lines of code.

cheers

andrew