Re: bug at build_dummy_tuple

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> This is a weird bug.  In a freshly initialized database, or just after
> deleting the pg_internal.init relcache file,
> SELECT 16854::regclass;
> crashes the backend.

Ah, I see it.  Looks like I was a bit too cute here:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/relcache.c.diff?r1=1.200;r2=1.201;f=h
in particular the change within formrdesc at about line 1316.

I was thinking that formrdesc needn't get the relcache's tuple
descriptor (rel->rd_att) completely right, since it would get fixed up
during RelationCacheInitializePhase2.  However, that routine uses
SearchSysCache(RELOID), which means catcache.c will have to initialize
that catalog cache on first call, and when it does so, it copies the
not-yet-fully-valid tupdesc for pg_class from the relcache into the
catcache entry.  Any subsequent code path that looks at the tdtypeid or
tdhasoid fields of the RELOID catcache's tupdesc will see wrong data.

The reason it didn't crash in 7.4 was that the 7.4 coding forces the
hasoids bit true rather than false, which is no more "correct" than CVS
tip, but it happens to be right for pg_class which is the only case that
presently will be examined before RelationCacheInitializePhase2 fixes
everything.  I saw that the code was not setting the bit correctly and
misassumed that it was therefore a don't care :-(

The proper solution is to make sure that formrdesc can fill the tupdesc
completely correctly; that's just a matter of adding a couple more
parameters to it, since it's only used for a small set of nailed
relations.  Will fix.

            regards, tom lane