Re: [HACKERS] initdb problem - Mailing list pgsql-hackers

>
> > I think this padding works by adding bytes to the previous field so that
> > when the current field is written is is on the right boundary.
> >
> > Does this make sense, or am I barking up the wrong tree?
>
> You are correct.  I just don't know what the alignment issues are of
> double vs. int for our various character types.
>
> This is more of an academic question, because your Sparc problem is
> probably not that, but something else that I can reproduce now.
>
>
> --
> Bruce Momjian                          |  830 Blythe Avenue

Hi all,

    I  don't know if this is really related to the initdb problem
    discussion (haven't followed it enough). But seems so because
    it  fixes  a  damn  problem  during  index tuple insertion on
    CREATE TABLE into pg_attribute_relid_attnum_index.

    Anyway - this bug was really hard to find. During startup the
    relcache  reads  in  some  prepared  information  about index
    strategies from a file and then  reinitializes  the  function
    pointers  inside  the  scanKey data.  But for sake it assumed
    single attribute index tuples (hasn't that changed recently).
    Thus not all the strategies scanKey entries where initialized
    properly,  resulting  in  invalid  addresses  for  the  btree
    comparision functions.

    With  the  patch  at  the  end  the  regression  tests passed
    excellent except for the sanity_check that crashed at  vacuum
    and the misc test where the select unique1 from onek2 outputs
    the two rows in different order.

    Bruce, could you please apply it?


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) #


*** relcache.c.orig    Fri Aug 28 05:03:02 1998
--- relcache.c    Fri Aug 28 05:02:12 1998
***************
*** 1982,1991 ****
  #define SMD(i)    strat[0].strategyMapData[i].entry[0]

          /* have to reinit the function pointers in the strategy maps */
!         for (i = 0; i < am->amstrategies; i++)
              fmgr_info(SMD(i).sk_procedure,
                        &(SMD(i).sk_func));
!         SMD(i).sk_nargs = SMD(i).sk_func.fn_nargs;


          /*
--- 1982,1992 ----
  #define SMD(i)    strat[0].strategyMapData[i].entry[0]

          /* have to reinit the function pointers in the strategy maps */
!         for (i = 0; i < am->amstrategies * relform->relnatts; i++) {
              fmgr_info(SMD(i).sk_procedure,
                        &(SMD(i).sk_func));
!             SMD(i).sk_nargs = SMD(i).sk_func.fn_nargs;
!         }


          /*