CVS corruption/mistagging?
in [PgSql]
|
Prev: Bug: Buffer cache is not scan resistant
Next: CREATE DATABASE cannot be executed from a function or multi-command string
From: Kris Jurka on 14 Aug 2007 18:06 Looking into recent buildfarm failures on the 7.4 branch: http://www.pgbuildfarm.org/cgi-bin/show_status.pl It looks like parts of the CVS repository have been mistagged as belonging to REL7_4_STABLE or have been corrupted somehow: http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE I'm not sure what's going on here, but something has gone bad. Kris Jurka ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
From: Tom Lane on 14 Aug 2007 18:15 Kris Jurka <books(a)ejurka.com> writes: > It looks like parts of the CVS repository have been mistagged as belonging > to REL7_4_STABLE or have been corrupted somehow: > http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE Hmm ... btree_bit.c shouldn't be in 7.4 at all. I can't help thinking this has something to do with the recent CVS server move. Magnus, any thoughts? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
From: Tom Lane on 14 Aug 2007 20:01 Andrew Dunstan <andrew(a)dunslane.net> writes: > Looking at the Committers mail, it looks like there have only been two > very small commits since Michael's series of commits around 12 to 13.5 > hours ago, and before that nothing since around 28 hours ago. Do we have > a backup snapshot of the repo taken during that time that we can roll > back to? That might be simpler than doing surgery on the repo. It looks to me like the mistake was unrelated to any commit, and was made at Aug 12 09:50 UTC. (Aside from the file-timestamp evidence, caracara's build failure at 2007-08-12 213845 shows that the problem is more than 2 days old.) I count seven commits of my own and several of Michael's since then. If I'm right that a simple "cvs rtag" will fix it, I'd rather do that than try to reapply patches. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
From: Andrew Dunstan on 14 Aug 2007 19:34 Tom Lane wrote: > In the meantime, though, it's not quite clear why this would lead to > a buildfarm failure --- it should just mean a lot of extraneous files > appearing in a fresh checkout. (Looks a bit harder ... Oh, it looks > like btree_gist has some files that used to be autogenerated and are > now in CVS, so the bogusly new versions from CVS are suppressing the > desired generation from the old btree_num.c file.) > > > Looking at the Committers mail, it looks like there have only been two very small commits since Michael's series of commits around 12 to 13.5 hours ago, and before that nothing since around 28 hours ago. Do we have a backup snapshot of the repo taken during that time that we can roll back to? That might be simpler than doing surgery on the repo. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
From: Tom Lane on 14 Aug 2007 18:49
I wrote: > Kris Jurka <books(a)ejurka.com> writes: >> It looks like parts of the CVS repository have been mistagged as belonging >> to REL7_4_STABLE or have been corrupted somehow: >> http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE > Hmm ... btree_bit.c shouldn't be in 7.4 at all. I did a fresh checkout of the 7.4 branch and diff'd against my local copy, and it seems clear that every file that was not in 7.4 at all has had its HEAD version tagged as REL7_4_STABLE. The files that did exist then are all right. That's throughout the whole tree, not just in contrib/btree_gist. I have no idea how you make CVS do that, but I'm sure there is some magic one-liner for it. Checking the files in contrib/btree_gist on the CVS server gives a pretty good fix on who changed it and when: > ls -la total 466 drwxrwxr-x 6 scrappy dev 1024 Aug 14 22:30 . drwxrwxr-x 90 scrappy dev 2048 Aug 14 22:27 .. drwxrwxr-x 2 scrappy dev 512 Apr 20 15:16 Attic -r--r--r-- 1 tgl dev 9555 Jun 26 22:05 Makefile,v -r--r--r-- 1 258 dev 5870 Apr 20 16:19 README.btree_gist,v -r--r--r-- 1 meskes dev 12052 Aug 12 09:50 btree_bit.c,v -r--r--r-- 1 meskes dev 9921 Aug 12 09:50 btree_bytea.c,v -r--r--r-- 1 meskes dev 10246 Aug 12 09:50 btree_cash.c,v -r--r--r-- 1 meskes dev 11433 Aug 12 09:50 btree_date.c,v -r--r--r-- 1 meskes dev 10230 Aug 12 09:50 btree_float4.c,v -r--r--r-- 1 meskes dev 10093 Aug 12 09:50 btree_float8.c,v -r--r--r-- 1 meskes dev 33935 Aug 12 09:50 btree_gist.c,v -r--r--r-- 1 258 dev 4325 Apr 20 15:16 btree_gist.h,v -r--r--r-- 1 258 dev 58744 Apr 20 16:19 btree_gist.sql.in,v -r--r--r-- 1 meskes dev 14736 Aug 12 09:50 btree_inet.c,v -r--r--r-- 1 meskes dev 10253 Aug 12 09:50 btree_int2.c,v -r--r--r-- 1 meskes dev 10240 Aug 12 09:50 btree_int4.c,v -r--r--r-- 1 meskes dev 10254 Aug 12 09:50 btree_int8.c,v -r--r--r-- 1 meskes dev 18111 Aug 12 09:50 btree_interval.c,v -r--r--r-- 1 meskes dev 12025 Aug 12 09:50 btree_macaddr.c,v -r--r--r-- 1 meskes dev 14671 Aug 12 09:50 btree_numeric.c,v -r--r--r-- 1 meskes dev 9796 Aug 12 09:50 btree_oid.c,v -r--r--r-- 1 meskes dev 18247 Aug 12 09:50 btree_text.c,v -r--r--r-- 1 meskes dev 26180 Aug 12 09:50 btree_time.c,v -r--r--r-- 1 258 dev 29712 Apr 20 15:16 btree_ts.c,v -r--r--r-- 1 meskes dev 17588 Aug 12 09:50 btree_utils_num.c,v -r--r--r-- 1 meskes dev 8959 Aug 12 09:50 btree_utils_num.h,v -r--r--r-- 1 meskes dev 48824 Aug 12 09:50 btree_utils_var.c,v -r--r--r-- 1 meskes dev 7099 Aug 12 09:50 btree_utils_var.h,v drwxrwxr-x 3 scrappy dev 1024 Aug 14 22:27 data drwxrwxr-x 3 scrappy dev 1024 Aug 14 22:27 expected drwxrwxr-x 3 scrappy dev 1024 Aug 14 22:27 sql -r--r--r-- 1 meskes dev 10021 Aug 12 09:50 uninstall_btree_gist.sql,v Michael, want to fess up to what you did? In the meantime, though, it's not quite clear why this would lead to a buildfarm failure --- it should just mean a lot of extraneous files appearing in a fresh checkout. (Looks a bit harder ... Oh, it looks like btree_gist has some files that used to be autogenerated and are now in CVS, so the bogusly new versions from CVS are suppressing the desired generation from the old btree_num.c file.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org |