Re: CVS sources doesn't compiles
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
Import Notes
Reply to msg id not found: Pine.GSO.4.44.0208061603270.18973-100000@ra.sai.msu.suReference msg id not found: Pine.GSO.4.44.0208061603270.18973-100000@ra.sai.msu.su
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_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
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:
Show quoted text
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_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
"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:
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
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.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_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
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) ...