Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

Thomas Munro writes: > Ahh, I think I see it. This is an EXEC_BACKEND build farm animal. > Theory: After the backend we see had removed the scratch entry and > before it had restored it, another backend started up and ran > InitPredicateLocks(), which inserted a new scratch entry without > interl

Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

On Tue, Jul 25, 2017 at 7:24 AM, Tom Lane wrote: > Thomas Munro writes: >> Ahh, I think I see it. This is an EXEC_BACKEND build farm animal. >> Theory: After the backend we see had removed the scratch entry and >> before it had restored it, another backend started up and ran >> InitPredicateLock

Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

On Mon, Jul 24, 2017 at 11:51 AM, Thomas Munro wrote: > On Sun, Jul 23, 2017 at 8:32 AM, Tom Lane wrote: >> Meanwhile, it's still pretty unclear what happened yesterday on >> culicidae. > > That failure is indeed baffling. The only code that inserts > (HASH_ENTER[_NULL]) into PredicateLockTarget

Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

On Sun, Jul 23, 2017 at 8:32 AM, Tom Lane wrote: > Meanwhile, it's still pretty unclear what happened yesterday on > culicidae. That failure is indeed baffling. The only code that inserts (HASH_ENTER[_NULL]) into PredicateLockTargetHash: 1. CreatePredicateLock(). I would be a bug if that ever

Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

I wrote: > And, while I'm looking at this ... isn't this "scratch target" logic > just an ineffective attempt at waving a dead chicken? It's assuming > that freeing an entry in a shared hash table guarantees that it can > insert another entry. But that hash table is partitioned, meaning it has >

[HACKERS] Buildfarm failure and dubious coding in predicate.c

Buildfarm member culicidae just showed a transient failure in the 9.4 branch: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2017-07-21%2017%3A49%3A37 It's an assert trap, for which the buildfarm helpfully captured a stack trace: #0 __GI_raise (sig=sig@entry=6) at ../sysde

Re: [HACKERS] Buildfarm failures on woodlouse (in ecpg-check)

* I wrote: If there is interest in fixing this issue that is apparently limited to VS 2013, I will try and produce a proper patch. Patch. Perhaps surprisingly, the bug is in the failing test cases themselves, not ecpg. The CRT has two modes for its locale implementation: When called in a "g

Re: [HACKERS] Buildfarm failures on woodlouse (in ecpg-check)

* Andrew Dunstan wrote: On 06/11/2017 11:33 AM, Christian Ullrich wrote: To build correctly, it requires defining _WIN32_WINNT to be 0x600 or above (and using an SDK that knows about InitOnceExecuteOnce()). We already define _WIN32_WINNT to be 0x0600 on all appropriate platforms (Vista/200

Re: [HACKERS] Buildfarm failures on woodlouse (in ecpg-check)

On 06/11/2017 11:33 AM, Christian Ullrich wrote: > Hello, > > my buildfarm animal woodlouse (Visual Studio 2013 on Windows 7) > stopped working correctly some months ago. After Tom kindly prodded me > into fixing it, I noticed that I had configured it to skip the > ecpg-check step because one of

[HACKERS] Buildfarm failures on woodlouse (in ecpg-check)

Hello, my buildfarm animal woodlouse (Visual Studio 2013 on Windows 7) stopped working correctly some months ago. After Tom kindly prodded me into fixing it, I noticed that I had configured it to skip the ecpg-check step because one of the tests in the "thread" section (not always the same) n

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 21:19, Mikael Kjellström wrote: Thanks. Will try it out. Just wanted to report that I've tried it and it works as expected. Thanks for the really fast fixes. /Mikael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 21:10, Andrew Dunstan wrote: Not sure I understand what "rerun a branch" from scratch means. If you zap the branch directory you lose all its state. That's generally a bad thing. I mean like the first time when you set up the buildfarm client / branch. And it's not something I

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 05/01/2017 03:00 PM, Mikael Kjellström wrote: > > On 2017-05-01 20:56, Andrew Dunstan wrote: >> OK, coming up with a more comprehensive fix. > > Ok. > >> The obvious workaround for now is to create the directory and dont zap >> it or its parents. You should only have to do it once (per branch)

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 20:56, Andrew Dunstan wrote: OK, coming up with a more comprehensive fix. Ok. The obvious workaround for now is to create the directory and dont zap it or its parents. You should only have to do it once (per branch) Yes, I know. That is what I have been doing so far. But if

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 05/01/2017 02:46 PM, Mikael Kjellström wrote: > > > On 2017-05-01 20:44, Mikael Kjellström wrote: >> Nope, that didn't do it. > > Or well. It fixed the check_make bug but not the other bug with that > the loach.lastrun-logs-directory isn't created before trying to write > to it. > OK, comin

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 20:44, Mikael Kjellström wrote: Nope, that didn't do it. Or well. It fixed the check_make bug but not the other bug with that the loach.lastrun-logs-directory isn't created before trying to write to it. /Mikael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-05-01 20:25, Andrew Dunstan wrote: OK, that's a bug. Mea culpa. the quick fix is this patch: diff --git a/run_build.pl b/run_build.pl index aeb8966..822b4de 100755 --- a/run_build.pl +++ b/run_build.pl @@ -1008,7 +1008,8 @@ sub writelog sub check_make {

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 05/01/2017 02:13 PM, Mikael Kjellström wrote: > On 2017-04-19 15:59, Andrew Dunstan wrote: > > >> I have released version 4.19 of the PostgreSQL Buildfarm client. It can >> be downloaded from >> >> > > I don't know if it

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 05/01/2017 02:13 PM, Mikael Kjellström wrote: > On 2017-04-19 15:59, Andrew Dunstan wrote: > > >> I have released version 4.19 of the PostgreSQL Buildfarm client. It can >> be downloaded from >> >> > > I don't know if it

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 2017-04-19 15:59, Andrew Dunstan wrote: I have released version 4.19 of the PostgreSQL Buildfarm client. It can be downloaded from I don't know if it's only me or if others have noticed this also but I have the buil

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

On 04/19/2017 01:38 PM, Tom Lane wrote: > Andrew Dunstan writes: >> I have released version 4.19 of the PostgreSQL Buildfarm client. It can >> be downloaded from >> > Nice work! > Thank you. >> * Improvements to TAP

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

Andrew Dunstan writes: > I have released version 4.19 of the PostgreSQL Buildfarm client. It can > be downloaded from > Nice work! > * Improvements to TAP tests logging and coverage. Each test set (i.e > each /t dire

[HACKERS] BuildFarm client release 4.19

I have released version 4.19 of the PostgreSQL Buildfarm client. It can be downloaded from Apart from some minor bug fixes, the following changes are made: * Include the script's path in @INC. That means you can usually

[HACKERS] buildfarm client release 4.18

I have just released buildfarm client version 4.18. In addition to some minor fixes, there are two significant changes: * The client now makes a determined effort to clean up any left over build artefacts from previous runs at the start of a run. It also tries to clean away old socket

[HACKERS] Buildfarm server move complete

The buildfarm server move is complete. Thanks to all who helped, especially Stephen Frost. There might be some small performance regressions which we'll be digging into. Next step: move the mailing lists off pgfoundry. The new lists have been set up I will be working on that migration next

Re: [HACKERS] Buildfarm server move

On 01/18/2016 05:20 PM, Andrew Dunstan wrote: People, Apologies for the late notice. Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will be moving the buildfarm server from its current home at CommandPrompt, where we have been ever since we started, to a machine that i

Re: [HACKERS] Buildfarm server move

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will > > be moving the buildfarm server from its current home at CommandPrompt, > > Um, this message is postmarked 18 Jan 17:20, an hour later than

Re: [HACKERS] Buildfarm server move

Andrew Dunstan writes: > Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will > be moving the buildfarm server from its current home at CommandPrompt, Um, this message is postmarked 18 Jan 17:20, an hour later than the stated move time. Did you mean the move will be Tue 19

[HACKERS] Buildfarm server move

People, Apologies for the late notice. Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will be moving the buildfarm server from its current home at CommandPrompt, where we have been ever since we started, to a machine that is part of the standard core infrastructure. In do

Re: [HACKERS] buildfarm failures on crake and sittella

On Sat, Oct 17, 2015 at 12:26 PM, Andrew Dunstan wrote: > I have done this and everything seems to be working. In the RedisFDW case, > it does process certain quals (those in the form "key" = ), but it > has been doing the same thing in redisGetForeignPlan as filefdw does in > fileGetForeignPlan,

Re: [HACKERS] buildfarm failures on crake and sittella

On 10/16/2015 02:19 PM, Andrew Dunstan wrote: On 10/16/2015 11:13 AM, Robert Haas wrote: Andrew, The FileTextArrayFDW-build failure on crake, and the RedisFDW-build failure on sittella, are expected results of my commit 5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push qu

Re: [HACKERS] buildfarm failures on crake and sittella

On 10/16/2015 11:13 AM, Robert Haas wrote: Andrew, The FileTextArrayFDW-build failure on crake, and the RedisFDW-build failure on sittella, are expected results of my commit 5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push quals down, they just need to be updated to pass an

[HACKERS] buildfarm failures on crake and sittella

Andrew, The FileTextArrayFDW-build failure on crake, and the RedisFDW-build failure on sittella, are expected results of my commit 5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push quals down, they just need to be updated to pass an additional NIL argument to make_foreignscan().

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Jeff Janes writes: > On Tue, Jul 28, 2015 at 2:38 PM, Tom Lane wrote: >> Rather than remove the "sending signal" elog entirely, I reduced it to >> DEBUG1; that will avoid log chatter for normal cases but the info can >> still be obtained at need. > This part doesn't seem right to me. Now the au

Re: [HACKERS] Buildfarm failure from overly noisy warning message

On Tue, Jul 28, 2015 at 2:38 PM, Tom Lane wrote: > Kevin Grittner writes: > > Tom Lane wrote: > >> Kevin Grittner writes: > >>> I think a LOG entry when an autovacuum process is actually canceled > >>> has value just in case it is happening on a particular table so > >>> frequently that the ta

Re: [HACKERS] buildfarm does not test "make check"

On 08/14/2015 09:27 AM, Robert Haas wrote: On Thu, Aug 13, 2015 at 2:11 PM, Alvaro Herrera wrote: So I added the brin isolation test back. Because it needs the pageinspect module, it can only work under "make check", not installcheck. The problem is that this means buildfarm will not run it

Re: [HACKERS] buildfarm does not test "make check"

On Thu, Aug 13, 2015 at 2:11 PM, Alvaro Herrera wrote: > So I added the brin isolation test back. Because it needs the > pageinspect module, it can only work under "make check", not > installcheck. The problem is that this means buildfarm will not run it, > because it only runs installcheck :-(

Re: [HACKERS] buildfarm does not test "make check"

On 08/13/2015 02:52 PM, Alvaro Herrera wrote: You're also going to have to handle the msvc side of things. That won't be trivial. See discussion elsewhere today about how we've got that wrong recently. Oh my. The pg_upgrade code in src/tools/msvc/vcregress.pl looks rather unhealthy, and I don

Re: [HACKERS] buildfarm does not test "make check"

Andrew Dunstan wrote: > The buildfarm server doesn't control anything the clients do except it > provides them with a list of branches we are interested in. Even that is > invisible to the main program, and only used by the wrapper run_branches.pl. > The main program can run entirely offline and I

Re: [HACKERS] buildfarm does not test "make check"

On 08/13/2015 02:11 PM, Alvaro Herrera wrote: So I added the brin isolation test back. Because it needs the pageinspect module, it can only work under "make check", not installcheck. The problem is that this means buildfarm will not run it, because it only runs installcheck :-( I realized th

[HACKERS] buildfarm does not test "make check"

So I added the brin isolation test back. Because it needs the pageinspect module, it can only work under "make check", not installcheck. The problem is that this means buildfarm will not run it, because it only runs installcheck :-( I realized that the important modules that run under "make chec

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On 07/28/2015 08:58 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/27/2015 10:06 AM, Tom Lane wrote: I think we should disable TAP testing in the buildfarm until there is some credible form of error reporting for it. The situation should now be substantially improved. Hm, I was just think

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

Andrew Dunstan writes: >> On 07/27/2015 10:06 AM, Tom Lane wrote: >>> I think we should disable TAP testing in the buildfarm until there is >>> some credible form of error reporting for it. > The situation should now be substantially improved. Hm, I was just thinking we weren't there yet, becaus

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On 07/27/2015 12:15 PM, Andrew Dunstan wrote: On 07/27/2015 10:06 AM, Tom Lane wrote: I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Kevin Grittner writes: > Tom Lane wrote: >> Kevin Grittner writes: >>> I think a LOG entry when an autovacuum process is actually canceled >>> has value just in case it is happening on a particular table so >>> frequently that the table starts to bloat. I see no reason to log >>> anything if th

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On Tue, Jul 28, 2015 at 1:15 AM, Andrew Dunstan wrote: > Well, it does create a lot of files that we don't pick up. An example list > is show below, and I am attaching their contents in a single gzipped > attachment. However, these are in the wrong location. This was a vpath build > and yet these

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On 07/27/2015 10:06 AM, Tom Lane wrote: I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-07-04%2016%3A00%3A23 or here: h

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On 07/27/2015 05:06 PM, Tom Lane wrote: I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-07-04%2016%3A00%3A23 or here: ht

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Tom Lane wrote: > Kevin Grittner writes: >> I think a LOG entry when an autovacuum process is actually canceled >> has value just in case it is happening on a particular table so >> frequently that the table starts to bloat. I see no reason to log >> anything if there is an intention to cancel

[HACKERS] Buildfarm TAP testing is useless as currently implemented

I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-07-04%2016%3A00%3A23 or here: http://buildfarm.postgresql.org/cgi-bin/show

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Kevin Grittner writes: > Tom Lane wrote: >> What's evidently happened here is that our session tried to boot an >> autovacuum process off a table lock, only that process was gone by the >> time we issued the kill() call. > I think a LOG entry when an autovacuum process is actually canceled > has

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Tom Lane wrote: > + WARNING: could not send signal to process 30123: No such process > What's evidently happened here is that our session tried to boot an > autovacuum process off a table lock, only that process was gone by the > time we issued the kill() call. > I'm inclined to reduce the WAR

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Andrew Dunstan writes: > On 07/26/2015 11:00 AM, Andres Freund wrote: >> On 2015-07-26 10:56:05 -0400, Tom Lane wrote: >>> I'm inclined to reduce the WARNING to LOG >> Hm, that doesn't seem like a very nice solution, given that LOG is even >> more likely to end up in the server log. >>> and/or s

Re: [HACKERS] Buildfarm failure from overly noisy warning message

On 07/26/2015 11:00 AM, Andres Freund wrote: Hi, On 2015-07-26 10:56:05 -0400, Tom Lane wrote: CREATE INDEX tenk2_unique1 ON tenk2 USING btree(unique1 int4_ops); + WARNING: could not send signal to process 30123: No such process What's evidently happened here is that our session tried to b

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Hi, On 2015-07-26 10:56:05 -0400, Tom Lane wrote: > CREATE INDEX tenk2_unique1 ON tenk2 USING btree(unique1 int4_ops); > + WARNING: could not send signal to process 30123: No such process > What's evidently happened here is that our session tried to boot an > autovacuum process off a table loc

[HACKERS] Buildfarm failure from overly noisy warning message

chipmunk failed last night http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2015-07-26%2007%3A36%3A32 like so: == pgsql.build/src/test/regress/regression.diffs === *** /home/pgbfarm/buildroot/REL9_3_STABLE/pgsql.build/src/test/regress/expected/c

Re: [HACKERS] Buildfarm client version 4.15 released

Unfortunately, this release contained a bug that only affects MSVC builds, which would silently fail on HEAD. There is a bug fix release available at or you can just pick up the fixed version of run_build.pl (the only thin

[HACKERS] Buildfarm client version 4.15 released

I have just released version 4.15 of the PostgreSQL Buildfarm Client . It can be downloaded at Here's what's changed: * support the new location for pg_upgr

Re: [HACKERS] Buildfarm has got the measles

Tom Lane wrote: > Evidently the order in which child tables are visited isn't too stable. > I'm inclined to think that that's fine and this regression test needs > reconsideration. Thanks for pointing it out. I was going to just drop one of the tables, but then thought it is worth keeping a rewr

[HACKERS] Buildfarm has got the measles

A significant fraction of the buildfarm is showing this in HEAD: *** *** 375,382 create table rewritemetoo1 of rewritetype; create table rewritemetoo2 of rewritetype; alter type rewritetype alter attribute a type text cascade; - NOTICE: Table 'rewritemetoo1' is being rewrit

Re: [HACKERS] Buildfarm broken for 9.3 and up

On 01/30/2015 11:00 AM, Tom Lane wrote: I do see that macque is having issues, but it's been busted for the past 3 days it looks like. Yeah. Several of the critters have been having git issues for weeks to months. I wonder whether we couldn't teach the buildfarm script to recover from this

Re: [HACKERS] Buildfarm broken for 9.3 and up

Stephen Frost writes: > * Kevin Grittner (kgri...@ymail.com) wrote: >> My push to branches 9.3 and up seems to have broken the buildfarm >> with this: > I don't think it has anything to do with your push. A number of members > have built with your latest and look fine at this point, and I'm not

Re: [HACKERS] Buildfarm broken for 9.3 and up

Kevin, * Kevin Grittner (kgri...@ymail.com) wrote: > My push to branches 9.3 and up seems to have broken the buildfarm > with this: I don't think it has anything to do with your push. A number of members have built with your latest and look fine at this point, and I'm not seeing any issues here

Re: [HACKERS] Buildfarm broken for 9.3 and up

On 2015-01-30 15:34:02 +, Kevin Grittner wrote: > My push to branches 9.3 and up seems to have broken the buildfarm > with this: I think this isn't anything related to your commit. Both racoon and macaque have failed for a while. They just happened to run quickly after your commit, giving the

Re: [HACKERS] Buildfarm broken for 9.3 and up

Kevin Grittner wrote: > My push to branches 9.3 and up seems to have broken the buildfarm > with this: > > error: object file > /home/pgfarm/buildroot/pgmirror.git/objects/93/d7706cbf2ce58e63ab8bbc9d16453b2c792ed4 > is empty > error: unable to find 93d7706cbf2ce58e63ab8bbc9d16453b2c792ed4 > fat

[HACKERS] Buildfarm broken for 9.3 and up

My push to branches 9.3 and up seems to have broken the buildfarm with this: error: object file /home/pgfarm/buildroot/pgmirror.git/objects/93/d7706cbf2ce58e63ab8bbc9d16453b2c792ed4 is empty error: unable to find 93d7706cbf2ce58e63ab8bbc9d16453b2c792ed4 fatal: SHA1 COLLISION FOUND WITH 93d7706c

Re: [HACKERS] Buildfarm not happy with test module move

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Sounds good to me. The other parts of the core tests that depend on > >> contrib modules aren't exactly good models to follow. > > > Pushed; tests pass for me, let's see what buildfarm says. > > Pushed? Don't see it ... Meh. D

Re: [HACKERS] Buildfarm not happy with test module move

Alvaro Herrera writes: > Tom Lane wrote: >> Sounds good to me. The other parts of the core tests that depend on >> contrib modules aren't exactly good models to follow. > Pushed; tests pass for me, let's see what buildfarm says. Pushed? Don't see it ... regards, tom la

Re: [HACKERS] Buildfarm not happy with test module move

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> All of the MSVC critters are failing at "make check". > > > Yeah, I noticed that, thanks. As far as I can see the only way to fix > > it is to install dummy_seclabel to run the core seclabel test. That > > doesn't seem smart; I t

Re: [HACKERS] Buildfarm not happy with test module move

On Mon, Dec 1, 2014 at 1:41 PM, Alvaro Herrera wrote: > Magnus Hagander wrote: >> On Mon, Dec 1, 2014 at 2:22 AM, Tom Lane wrote: >> > Alvaro Herrera writes: >> >> That was my fault -- the alvh.no-ip.org domain was deleted, and the >> >> email system in postgresql.org rejected the commit message

Re: [HACKERS] Buildfarm not happy with test module move

Magnus Hagander wrote: > On Mon, Dec 1, 2014 at 2:22 AM, Tom Lane wrote: > > Alvaro Herrera writes: > >> That was my fault -- the alvh.no-ip.org domain was deleted, and the > >> email system in postgresql.org rejected the commit message because the > >> sender was not in a deliverable domain. I

Re: [HACKERS] Buildfarm not happy with test module move

On Mon, Dec 1, 2014 at 2:22 AM, Tom Lane wrote: > Alvaro Herrera writes: >> That was my fault -- the alvh.no-ip.org domain was deleted, and the >> email system in postgresql.org rejected the commit message because the >> sender was not in a deliverable domain. I noticed within a few hours, >> bu

Re: [HACKERS] Buildfarm not happy with test module move

Alvaro Herrera writes: > Tom Lane wrote: >> All of the MSVC critters are failing at "make check". > Yeah, I noticed that, thanks. As far as I can see the only way to fix > it is to install dummy_seclabel to run the core seclabel test. That > doesn't seem smart; I think it'd be better to remove

Re: [HACKERS] Buildfarm not happy with test module move

Tom Lane wrote: > All of the MSVC critters are failing at "make check". Yeah, I noticed that, thanks. As far as I can see the only way to fix it is to install dummy_seclabel to run the core seclabel test. That doesn't seem smart; I think it'd be better to remove that part of the core seclabel te

Re: [HACKERS] buildfarm and "rolling release" distros

Re: Craig Ringer 2014-07-02 <53b39638.9010...@2ndquadrant.com> > > +1. The buildfarm has one such member already, anchovy, and I recall it > > having given at least one helpful forewarning. It shows as "Arch Linux > > testing [updated daily]", which is sufficient annotation for me. Its > > fail

Re: [HACKERS] buildfarm and "rolling release" distros

On 07/02/2014 10:58 AM, Noah Misch wrote: > On Tue, Jul 01, 2014 at 08:35:16PM -0400, Tom Lane wrote: >> Robert Haas writes: >>> On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: I'm also not sure how to designate these machines. The buildfarm server metadata isn't designed for aut

Re: [HACKERS] buildfarm and "rolling release" distros

On Tue, Jul 01, 2014 at 08:35:16PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: > >> I'm also not sure how to designate these machines. The buildfarm server > >> metadata isn't designed for auto-updating build platforms. But no doubt if >

Re: [HACKERS] buildfarm and "rolling release" distros

Robert Haas writes: > On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: >> I've always been a bit reluctant to accept buildfarm members that are >> constantly being updated, because it seemed to me that it created something >> with too many variables. However, we occasionally get requests fr

Re: [HACKERS] buildfarm and "rolling release" distros

On 02/07/14 06:02, Robert Haas wrote: On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: I've always been a bit reluctant to accept buildfarm members that are constantly being updated, because it seemed to me that it created something with too many variables. However, we occasionally get re

Re: [HACKERS] buildfarm and "rolling release" distros

On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: > I've always been a bit reluctant to accept buildfarm members that are > constantly being updated, because it seemed to me that it created something > with too many variables. However, we occasionally get requests from people > who want to ru

[HACKERS] buildfarm and "rolling release" distros

I've always been a bit reluctant to accept buildfarm members that are constantly being updated, because it seemed to me that it created something with too many variables. However, we occasionally get requests from people who want to run on such platforms, and I'm also a bit reluctant to turn

[HACKERS] buildfarm client release 4.13

I have released version 4.13 of the PostgreSQL Buildfarm client. This can be downloaded from Changes in this release (from the git log): fcc182b Don't run TestCollateLinuxUTF8 on unsupported branches. 273af50 Don't run

Re: plpython_unicode test (was Re: [HACKERS] buildfarm / handling (undefined) locales)

I wrote: > Andrew Dunstan writes: >> Let's just stick to ASCII. > The more I think about it, the more I think that using a plain-ASCII > character would defeat most of the purpose of the test. Non-breaking > space seems like the best bet here, not least because it has several > different represe

Re: plpython_unicode test (was Re: [HACKERS] buildfarm / handling (undefined) locales)

Andrew Dunstan writes: > On 06/01/2014 05:35 PM, Tom Lane wrote: >> I did a little bit of experimentation and determined that none of the >> LATIN1 characters are significantly more portable than what we've got: >> for instance a-acute fails to convert into 16 of the 33 supported >> server-side en

Re: plpython_unicode test (was Re: [HACKERS] buildfarm / handling (undefined) locales)

On 06/01/2014 05:35 PM, Tom Lane wrote: I wrote: 3. Try to select some "more portable" non-ASCII character, perhaps U+00A0 (non breaking space) or U+00E1 (a-acute). I think this would probably work for most encodings but it might still fail in the Far East. Another objection is that the expec

Re: plpython_unicode test (was Re: [HACKERS] buildfarm / handling (undefined) locales)

I wrote: > 3. Try to select some "more portable" non-ASCII character, perhaps U+00A0 > (non breaking space) or U+00E1 (a-acute). I think this would probably > work for most encodings but it might still fail in the Far East. Another > objection is that the expected/plpython_unicode.out file would

plpython_unicode test (was Re: [HACKERS] buildfarm / handling (undefined) locales)

Tomas Vondra writes: > On 13.5.2014 20:58, Tom Lane wrote: >> Tomas Vondra writes: >>> Yeah, not really what we were shooting for. I've fixed this by >>> defining the missing locales, and indeed - magpie now fails in >>> plpython tests. >> I saw that earlier today (tho right now the buildfarm se

Re: [HACKERS] buildfarm / handling (undefined) locales

On 13.5.2014 20:58, Tom Lane wrote: > Tomas Vondra writes: >> Yeah, not really what we were shooting for. I've fixed this by >> defining the missing locales, and indeed - magpie now fails in >> plpython tests. > > I saw that earlier today (tho right now the buildfarm server seems > to not be res

Re: [HACKERS] buildfarm animals and 'snapshot too old'

On 05/20/2014 09:42 AM, Tom Lane wrote: Regarding clock skew, I think we can do better then what you suggest. The web transaction code in the client adds its own timestamp just before running the web transaction. It would be quite reasonable to reject reports from machines with skewed clocks ba

Re: [HACKERS] buildfarm animals and 'snapshot too old'

On 05/20/2014 03:59 PM, Gavin Flower wrote: On 21/05/14 01:42, Tom Lane wrote: Andrew Dunstan writes: On 05/20/2014 07:09 AM, Tom Lane wrote: Robert's got a point here. In my usage, the annoying thing is not animals that take a long time to report in; it's the ones that lie about the snapsh

Re: [HACKERS] buildfarm animals and 'snapshot too old'

On 21/05/14 01:42, Tom Lane wrote: Andrew Dunstan writes: On 05/20/2014 07:09 AM, Tom Lane wrote: Robert's got a point here. In my usage, the annoying thing is not animals that take a long time to report in; it's the ones that lie about the snapshot time (which is how you get "512abc4 in the

Re: [HACKERS] buildfarm animals and 'snapshot too old'

Andrew Dunstan writes: > On 05/20/2014 07:09 AM, Tom Lane wrote: >> Robert's got a point here. In my usage, the annoying thing is not animals >> that take a long time to report in; it's the ones that lie about the >> snapshot time (which is how you get "512abc4 in the middle of a bunch of >> ef9a

Re: [HACKERS] buildfarm animals and 'snapshot too old'

On 05/20/2014 07:09 AM, Tom Lane wrote: Robert Haas writes: On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan wrote: Well, the original code was put in for a reason, presumably that we were getting some stale data and wanted to exclude it. So I'm unwilling to throw it out altogether. If someon

Re: [HACKERS] buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)

On 2014-05-19 13:45:15 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-05-19 11:25:04 -0400, Tom Lane wrote: > >> No, we'd have two independent entries, each with its own correct refcount. > >> When the refcount on the no-longer-linked-in-the-hashtable entry goes to > >> zero, it'd be l

Re: [HACKERS] buildfarm animals and 'snapshot too old'

Robert Haas writes: > On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan wrote: >> Well, the original code was put in for a reason, presumably that we were >> getting some stale data and wanted to exclude it. So I'm unwilling to throw >> it out altogether. If someone can propose a reasonable sanity

Re: [HACKERS] buildfarm animals and 'snapshot too old'

On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan wrote: > Well, the original code was put in for a reason, presumably that we were > getting some stale data and wanted to exclude it. So I'm unwilling to throw > it out altogether. If someone can propose a reasonable sanity check then I'm > prepared

Re: [HACKERS] buildfarm animals and 'snapshot too old'

Andrew Dunstan writes: > Well, the original code was put in for a reason, presumably that we were > getting some stale data and wanted to exclude it. So I'm unwilling to > throw it out altogether. If someone can propose a reasonable sanity > check then I'm prepared to implement it. Would it be

Re: [HACKERS] buildfarm animals and 'snapshot too old'

On 05/19/2014 05:37 PM, Tomas Vondra wrote: IMHO the problem is that d6a97674 was the last revision in the REL9_3_STABLE branch when the test started (00:14), but at 06:06 777d07d7 got committed. So the check at the end failed, because the tested revision was suddenly ~2 days over the limit. T

Re: [HACKERS] buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)

Andres Freund writes: > On 2014-05-19 23:40:32 +0200, Tomas Vondra wrote: >> I was however wondering if this might be related to OOM errors a few >> local users reported to us. IIRC they've been using temporary tables >> quite heavily - not sure if that could be related. > I've significant doubts

Re: [HACKERS] buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)

On 2014-05-19 23:40:32 +0200, Tomas Vondra wrote: > On 19.5.2014 22:11, Tom Lane wrote: > > Tomas Vondra writes: > > I intentionally didn't do that, first because I have only a limited > > amount of confidence in the patch, and second because I don't think > > it matters for anything except CLOBBE

  1   2   3   4   5   >