Thread: CVS sources doesn't compiles
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.o heapam.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' make[3]: *** [heap-recursive] Error 2 make[3]: Leaving directory /db1/pgsql/cvs/pgsql-serve 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
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.o heapam.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' > make[3]: *** [heap-recursive] Error 2 > make[3]: Leaving directory /db1/pgsql/cvs/pgsql-serve > I get this too. I think there may be a CVS problem of some sort. Through the web interface, it's clear that src/include/utils/rel.h (the relevant include file) has been at version 1.61 (2002/08/06 02:36:35) for 10 hours -and the last change to it added rd_istemp and rd_isnew. However, cvs log (for me, on anonymous CVS) still shows rel.h at 1.60. Meanwhile, src/backend/access/heap/heapam.c is at 1.144 (updated 2002/08/06 02:36:33) It seems that bits of updates are going missing somewhere -so its not surprising that it won't compile. Regards John -- John Gray Azuli IT www.azuli.co.uk
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.o
heapam.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 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 ...
regards, tom lane
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.o
heapam.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_indexlistis 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
On Tue, 6 Aug 2002, 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.o heapam.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? sorry, it's cut-n-paste problem in editor (joe) I used to compose message. Vi is smarter about this. > > 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 ... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > 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
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
>
>
>
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
"Marc G. Fournier" <scrappy@hub.org> writes:
> 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?
Yes. I had just finished pulling a checkout from the anoncvs server,
and it was indeed out of sync. A cvs update now brings it back in sync.
Wonder why rsync stopped working?
regards, tom lane
On Tue, 6 Aug 2002, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: > > 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? > > Yes. I had just finished pulling a checkout from the anoncvs server, > and it was indeed out of sync. A cvs update now brings it back in sync. > > Wonder why rsync stopped working? Not sure, cause it works if I do it from the command line :( CVSup should be updating every hour, on the :59 (just like rsync was setup for) ...