Re: CVS sources doesn't compiles

It works now

On Tue, 6 Aug 2002, Marc G. Fournier wrote:

>
> 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
> >
> >
> >
>
Regards,    Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83