Re: CVS sources doesn't compiles - Mailing list pgsql-hackers
From | Marc G. Fournier |
---|---|
Subject | Re: CVS sources doesn't compiles |
Date | |
Msg-id | 20020806112856.O83339-100000@mail1.hub.org Whole thread Raw |
In response to | Re: CVS sources doesn't compiles (John Gray <jgray@azuli.co.uk>) |
Responses |
Re: CVS sources doesn't compiles
Re: CVS sources doesn't compiles |
List | pgsql-hackers |
Try it now ... rsycn, for some reason, is dumping core, so I just swithed to using CVSup to pull it down ... does that fix it? On 6 Aug 2002, John Gray wrote: > On Tue, 2002-08-06 at 14:49, Tom Lane wrote: > > John Gray <jgray@azuli.co.uk> writes: > > > On Tue, 2002-08-06 at 14:03, Oleg Bartunov wrote: > > >> make[4]: Entering directory /db1/pgsql/cvs/pgsql-server/src/backend/access/heap' > > >> gcc -O2 -mpentiumpro -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -c -o heapam.oheapam.c > > >> heapam.c: In function eap_insert': > > >> heapam.c:1158: structure has no member named d_istemp' > > >> heapam.c: In function eap_delete': > > >> heapam.c:1341: structure has no member named d_istemp' > > >> heapam.c: In function eap_update': > > >> heapam.c:1677: structure has no member named d_istemp' > > >> make[4]: *** [heapam.o] Error 1 > > >> make[4]: Leaving directory /db1/pgsql/cvs/pgsql-server/src/backend/access/heap' > > > > Control-H? Control-R? You seem to have a corrupted copy of heapam.c. > > If you move it out of the way and do a "cvs update", do you get a copy > > with the identical errors? > > > > I should have checked what I was quoting first! The messages I get have > no funny characters in -and the reason for the error is that rel.h has > the following (as you can see, it doesn't have rd_istemp replacing > rd_myxactonly): > > /* > * Here are the contents of a relation cache entry. > */ > > typedef struct RelationData > { > File rd_fd; /* open file descriptor, > or -1 if none */ > RelFileNode rd_node; /* file node (physical > identifier) */ > BlockNumber rd_nblocks; /* number of blocks in rel */ > BlockNumber rd_targblock; /* current insertion target > block, or > * > InvalidBlockNumber */ > int rd_refcnt; /* reference > count */ > bool rd_myxactonly; /* rel uses the local buffer mgr > */ > bool rd_isnailed; /* rel is nailed in cache */ > bool rd_indexfound; /* true if rd_indexlist is valid > */ > bool rd_uniqueindex; /* true if rel is a UNIQUE index > */ > > [rest snipped]. This is version 1.60. Tom's patch produced 1.61. I can't > get anonCVS to give me 1.61. (But annoyingly, it gives me Tom's updated > heapam.c 1.144). > > > I can report that the master CVS server delivers a correct copy. If > > there is a CVS problem then it's only on the anoncvs mirror ... > > > > Well, that seems likely -as cvsweb reports the file OK. > > I wonder whether our CVS mirroring is sufficiently atomic? i.e. did we > get an inconsistent snapshot because it was taken partway through a > patch being applied. > > This is clearly going to be a bit of a pain if it is a consequence of > heavier development activity - not least because it consumes everyone's > time chasing imaginary bugs. I'm assuming that it will just be a > transient issue - but there has been no change in it for several hours, > so presumably the mirroring is not run that often... > > Regards > > John > > > -- > John Gray > Azuli IT > www.azuli.co.uk > > >
pgsql-hackers by date: