Re: XversionUpgrade tests broken by postfix operator removal
Andrew Dunstan wrote: > For reference, here is the complete hotfix. Applied on skate/snapper, mussurana/tadarida, ibisbill/kittiwake. Best regards, Tom Turelinckx
tadarida vs REL_12_STABLE
Hi, > On 2020-Apr-13, I wrote to buildfarm-admins: > > As skate and snapper are increasingly difficult to keep alive and > > building on debian sparc, and as there aren't many sparc animals > > in general, I've set up four new debian sparc64 animals, two on > > stretch and two on buster. > > > > All four animals are already successfully building all current > > branches, just not submitting results yet. It turns out I'd missed one failure: https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=tadarida&br=REL_12_STABLE Only tadarida fails the sequence regression test, and only for REL_12_STABLE. It fails with -O2 and -O1 but succeeds with -O0. Other than that, all branches for all four animals succeed: > mussurana | Debian | 9 Stretch | gcc | 6 | with cassert > tadarida | Debian | 9 Stretch | gcc | 6 | without cassert > ibisbill | Debian | 10 Buster | gcc | 8 | with cassert > kittiwake | Debian | 10 Buster | gcc | 8 | without cassert Both mussurana and tadarida are Stretch 9.12 with gcc 6.3.0-18+deb9u1. There is no newer gcc source pkg for stretch or for stretch-backports. Should I keep the -O0 flag for REL_12_STABLE for tadarida? Thanks, Tom
Re: snapper vs. HEAD
Hi, Tom Lane wrote: > Thanks! But it doesn't seem to have taken: snapper just did a new run > that still failed, and it still seems to be using -O2. Snapper did build using -O1 a few hours ago, but it failed the check stage very early with a different error: FATAL: null value in column "classid" of relation "pg_depend" violates not-null constraint I then cleared out the ccache and forced a build of HEAD: same issue. Next I cleared out the ccache and forced a build of HEAD with -O2: this is the one you saw. Finally, I've cleared out both the ccache and the accache and forced a build of HEAD with -O1. It failed the check stage again very early with the above error. > to move to a newer Debian LTS release? Or have they dropped Sparc > support altogether? Wheezy was the last stable release for Debian sparc. Sparc64 is a Debian ports architecture, but there are no stable releases for sparc64. I do maintain private sparc64 repositories for Stretch and Buster, and I could configure buildfarm animals for those (on faster hardware too), but those releases are not officially available. Best regards, Tom Turelinckx
Re: snapper vs. HEAD
Hi, Tom Lane wrote: > Confirmed: building gistget with --enable-cassert, and all of snapper's > compile/link options, produces something that passes regression. Skate uses buildfarm default configuration, whereas snapper uses settings which are used when building postgresql debian packages. Debian packages are built without --enable-cassert, but most buildfarm animals build with --enable-cassert. I specifically configured skate and snapper like that because I ran into such issues in the past (where debian packages would fail to build on sparc, but buildfarm animals on debian sparc did not highlight the issue). In the past, I've already switched from gcc 4.6 to gcc 4.7 as a workaround for a similar compiler bug, but I can't upgrade to a newer gcc without backporting it myself, so for the moment I've switched snapper to use -O1 instead of -O2, for HEAD only. Not sure whether wheezy on sparc 32-bit is very relevant today, but it's an exotic platform, so I try to keep those buildfarm animals alive as long as it's possible. Best regards, Tom Turelinckx
Re: "ago" times on buildfarm status page
On Mon, Aug 26, 2019, at 9:08 PM, Andrew Dunstan wrote: > I think this is the problem: > > 'scmrepo' => '/home/pgbf/pgmirror.git', > > Probably this isn't updated often enough. It probably has little to do with > the clock settings. > > This is the kind of old-fashioned way of doing things. These days > "git_keep_mirror => 1" along with the community repo as the base would avoid > these problems. We've discussed this before (see below). The configuration is intentionally like that. I specifically configured skate and snapper to build the exact same source, where skate builds with default buildfarm settings, while snapper builds with the settings actually used by Debian source packages. These animals were set up to avoid cases we had in the past where Debian source packages failed to build on sparc, even though build animals running on Debian sparc were building fine: https://www.postgresql.org/message-id/01d2f0c2%24e2d335a0%24a879a0e0%24%40turelinckx.be With snapper building the exact same source as skate (as it is now), we have some point of reference if snapper fails but skate succeeds. I could configure snapper to perform an update of the repo before building, but then we give up this comparability in exchange for a bit more clarity regarding timestamps. Best regards, Tom Turelinckx On Thu, Nov 9, 2017, at 8:54 PM, Andrew Dunstan wrote: > > The first line of the log file is always something like this (see end of > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2017-11-09%2018%3A59%3A01 > ) > > Last file mtime in snapshot: Thu Nov 9 17:56:07 2017 GMT > This should be the time of the last commit in the snapshot. > > On Mon, Nov 6, 2017 at 9:49 AM, Tom Lane wrote: >> >> Tom Turelinckx writes: >> >> > On Fri, Nov 3, 2017, at 09:42 PM, Tom Lane wrote: >> >> Either that, or it's fallen through a wormhole ;-), but the results >> >> it's posting seem to be mis-timestamped by several hours, which is >> >> confusing. Please set its clock correctly. Maybe spin up ntpd? >> >> > The clock is correct, but the configuration may be unusual. >> >> > In fact, snapper runs on the same machine as skate, and it's using ntp. >> > At 7 AM (Western Europe), a local git repo is updated. In the morning, >> > skate builds from that local repo with the default buildfarm >> > configuration that most animals use. In the afternoon, snapper builds >> > from that local repo with the exact same configuration, per branch, that >> > the Debian source packages from the pgdg repo use on the same platform. >> > The local repo is updated only once per day to ensure that snapper and >> > skate build the same source with different settings, and they share the >> > git mirror and build root, as suggested in the build farm howto. >> >> Hm. So the issue really is that the build timestamp that the buildfarm >> client is reporting tells when it pulled from the local repo, not when >> that repo was last updated from the community server. Not sure if there's >> any simple way to improve that ... Andrew, any thoughts?
RE: jsonpath
Tom Lane wrote: > I assume this trace is from this run? > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skate&dt=2019-03-31%2006%3A24%3A35 Yes. I did get a core file now, but it wasn't picked up by the buildfarm script, so I extracted the backtrace manually. > That looks a whole lot like the previous failure on snapper: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snapper&dt=2019-03-23%2013%3A01%3A28 That's what I meant. > Huh ... so that's nowhere near the jsonpath-syntax-error crash that > we saw before. Sorry, I wasn't aware there were multiple crashes. > BTW, what is the difference between skate and snapper? They look to > be running on the same machine. They are. Skate runs with default buildfarm options. Snapper mimics the options used by the pgdg debian source packages. Both build the same source (first skate then snapper). This to avoid a repeat of [1]. Snapper also runs more tests (UpgradeXversion, CollateLinuxUTF8). Best regards, Tom Turelinckx 1. https://www.postgresql.org/message-id/20160413175827.dmlbtdf7c3mgmnex%40alap3.anarazel.de
RE: jsonpath
Alexander Korotkov wrote: > Hmm... 550b9d26f just makes jsonpath_gram.y and jsonpath_scan.l > compile at once. I've re-read this commit and didn't find anything > suspicious. > I've asked Andrew for access to jacana in order to investigate this myself. Stack trace from skate: [New LWP 6614] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/sparc-linux-gnu/libthread_db.so.1". Core was generated by `postgres: pgbf regression [local] SELECT '. Program terminated with signal 11, Segmentation fault. #0 strlen () at ../sysdeps/sparc/sparc64/strlen.S:34 34 ldx [%o0], %o5 #0 strlen () at ../sysdeps/sparc/sparc64/strlen.S:34 #1 0x0008a3e4 in printtup (slot=0x834888, self=0x864cc0) at printtup.c:435 #2 0x00259b60 in ExecutePlan (execute_once=, dest=0x864cc0, direction=, numberTuples=0, sendTuples=true, operation=CMD_SELECT, use_parallel_mode=, planstate=0x833eb0, estate=0x833d70) at execMain.c:1686 #3 standard_ExecutorRun (queryDesc=0x7dcdc0, direction=, count=0, execute_once=) at execMain.c:365 #4 0x00259da0 in ExecutorRun (queryDesc=0x808920, queryDesc@entry=0x7dcdc0, direction=direction@entry=ForwardScanDirection, count=8801472, execute_once=) at execMain.c:309 #5 0x003e6714 in PortalRunSelect (portal=portal@entry=0x808920, forward=forward@entry=true, count=0, count@entry=2147483647, dest=dest@entry=0x864cc0) at pquery.c:929 #6 0x003e7d3c in PortalRun (portal=portal@entry=0x808920, count=count@entry=2147483647, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x864cc0, altdest=altdest@entry=0x864cc0, completionTag=completionTag@entry=0xff86e830 "") at pquery.c:770 #7 0x003e32d0 in exec_simple_query ( query_string=0x7ba400 "select '$.g ? (@.a == 1 || @.a == 4 && @.b == 7)'::jsonpath;") at postgres.c:1215 #8 0x003e4854 in PostgresMain (argc=, argv=argv@entry=0x7e2370, dbname=0x7e2148 "regression", username=) at postgres.c:4247 #9 0x0007ae6c in BackendRun (port=0x7ddd40) at postmaster.c:4399 #10 BackendStartup (port=0x7ddd40) at postmaster.c:4090 #11 ServerLoop () at postmaster.c:1703 #12 0x00353a68 in PostmasterMain (argc=argc@entry=6, argv=argv@entry=0x7b49a8) at postmaster.c:1376 #13 0x0007cc60 in main (argc=6, argv=0x7b49a8) at main.c:228 Does this help? Best regards, Tom Turelinckx
