Re: [HACKERS] Backend crashes - what's going on here???

Whow - gdb is a nice tool

>
> >
> > Hey,
> >
> > the current snapshot dumps core on the 4th time doing
> >
> > REVOKE ALL ON pg_user FROM public;
> >
> > It does too in other situations but this is the simplest to
> > reproduce. The segmentation fault happens in nocachegetattr()
> > due to a destroyed tuple descriptor (natts = 0!!! and the
> > others don't look good either) for the syscache 21 (USENAME).
> > But the destruction must happen somewhere else.
> >
> > With the 02/13 snapshot I haven't got any problems on it.
> > But cannot find the error with diff.
> >
> > BTW: Doing last checks on view permissions - sending a patch
> > soon.
>
> Yep, I saw this too when testing my password acl null patch. Couldn't
> reproduce it, so I thought it was a fluke.
>
> --
> Bruce Momjian
> maillist(at)candle(dot)pha(dot)pa(dot)us
>

Have a clue now what causes the crash. It happens when
pg_user is looked up in the syscache. It must have to do with
the fact that during initialization in miscinit.c on
SetUserId() the user tuple is fetched using
SearchSysCacheTuple(). Due to this the SysCache entry 21
gets initialized but later on start transaction through the
cache reset the memory for the cc_tupdesc in the cache is
freed. So I assume when SetUserId() is called, the syscache
is not ready for use yet.

I don't have a solution right now. Is someone more familiar
with the handling of the syscache during startup? Is
SetUserId() just called a little too early or is the syscache
unusable during InitPostgres at all?

But the fact that CatalogCacheInitializeCache() is called
only for pg_user during startup makes me feel sure that the
lookup of the user using SearchSysCacheTuple() is wrong at
this time. I think it sould be done without using the
syscache.

Back on monday - maybe with a solution.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #