Re: [HACKERS] initdb problem

From: jwieck(at)debis(dot)com (Jan Wieck)
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: emkxp01(at)mtcc(dot)demon(dot)co(dot)uk, meskes(at)online-club(dot)de, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] initdb problem
Date: 1998-08-28 03:24:18
Message-ID: m0zCF99-000EBPC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)debis(dot)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;
! }


/*

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-08-28 03:37:08 Re: [HACKERS] initdb problem
Previous Message Bruce Momjian 1998-08-28 00:24:20 Re: [HACKERS] initdb problem