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@candle.pha.pa.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@debis.com (Jan Wieck) #