Hi Michael You said:
> Setting up a buildfarm member with the combination of compiler and > environment where you are seeing the failures would be the best answer > in my opinion: > https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto > > This does not require special knowledge of PostgreSQL internals, and the > in-core testing framework has improved the last couple of years to allow > for more advanced tests. I do use it as well for some tests on my own > modules (company stuff). The buildfarm code has also followed the pace, > which really helps a lot, thanks to Andrew Dunstan. > > Developers and committers are more pro-active if they can see automated > tests failing in the central community place. And buildfarm animals > usually don't stay red for more than a couple of days. Hummmm I quickly read this HowTo and I did not find any explanation about the "protocole" used for exchanging data between my VM and the PostgreSQL BuildFarm. My machine is behind firewalls and have restricted access to the outside. Either I'll see when that does not work... or I can get some information about which port (or anything else) I have to ask to be opened, if needed. Anyway, I'll read it in depth now and I'll try to implement it. About the random error we see, I guess that I may see it, though PostgreSQL BuildFarm AIX VMs do not see it, because I'm using a not-too-small VM, using variable Physical Processing units (CPUs) since my VM is uncapped (I may use all Physical CPU if available): up to 4 physical processors and up to 8 virtual processors. And, on BuildFarm, I do not see any details about the logical/physical configuration of the AIX VMs, like hornet. Being able to run real concurrent parallel stress programs, thus required multi-physical-CPU VM, would help. Regards, Tony
