Re: pgsql: Implement channel binding tls-server-end-point for SCRAM
On 4 January 2018 at 21:02, Tom Lane wrote: > Peter Eisentraut writes: >> Implement channel binding tls-server-end-point for SCRAM > > Buildfarm doesn't like this one bit. Can't we automate these messages? Seems strange to send manual emails every time. We do know who the commits are coming from and we have their email address. It would be useful to get automatic message giving a summary of buildfarm results at 15, 30 and 60 minute intervals, even if it is just ALL CLEAR. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Buildfarm status monitoring (was Re: pgsql: Implement channel binding tls-server-end-point for SCRAM)
Simon Riggs writes: > On 4 January 2018 at 21:02, Tom Lane wrote: >> Peter Eisentraut writes: >>> Implement channel binding tls-server-end-point for SCRAM >> Buildfarm doesn't like this one bit. > Can't we automate these messages? It's not that easy. First, the buildfarm gets random failures all the time, due to this and that. Second, if several commits have occurred since the critter's last run, it requires some human judgment to figure out which commit is probably to blame. You could ameliorate the first problem by waiting for multiple failures to show up ... but the longer you wait, the worse the second problem becomes (and the less useful the report would be anyway). > It would be useful to get automatic message giving a summary of > buildfarm results at 15, 30 and 60 minute intervals, even if it is > just ALL CLEAR. The raw result of that would be too noisy to be useful. I've wondered about getting the buildfarm status page to filter out the more obvious classes of "random failure" --- git pull failures would be one, and another would be if "no space left on device" appears anywhere in any of the report's log files. Don't know how far that would get us, though. regards, tom lane
Re: Buildfarm status monitoring (was Re: pgsql: Implement channel binding tls-server-end-point for SCRAM)
On 01/08/2018 11:01 AM, Tom Lane wrote: > Simon Riggs writes: >> On 4 January 2018 at 21:02, Tom Lane wrote: >>> Peter Eisentraut writes: Implement channel binding tls-server-end-point for SCRAM >>> Buildfarm doesn't like this one bit. >> Can't we automate these messages? > It's not that easy. First, the buildfarm gets random failures all the > time, due to this and that. Second, if several commits have occurred > since the critter's last run, it requires some human judgment to figure > out which commit is probably to blame. > > You could ameliorate the first problem by waiting for multiple failures > to show up ... but the longer you wait, the worse the second problem > becomes (and the less useful the report would be anyway). > >> It would be useful to get automatic message giving a summary of >> buildfarm results at 15, 30 and 60 minute intervals, even if it is >> just ALL CLEAR. > The raw result of that would be too noisy to be useful. I've wondered > about getting the buildfarm status page to filter out the more obvious > classes of "random failure" --- git pull failures would be one, and > another would be if "no space left on device" appears anywhere in any > of the report's log files. Don't know how far that would get us, though. > > Without triangulating via something like git-bisect I suspect we'd very soon find any automated system very tiresome indeed. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql: Cosmetic improvements in condition_variable.[hc].
Cosmetic improvements in condition_variable.[hc]. Clarify a bunch of comments. Discussion: https://postgr.es/m/CAEepm=0nwkehyw7ndousf8juukoprncyy3vuasvhrewsota...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e35dba475a440f73dccf9ed1fd61e3abc6ee61db Modified Files -- src/backend/storage/lmgr/condition_variable.c | 92 +-- src/include/storage/condition_variable.h | 23 --- 2 files changed, 70 insertions(+), 45 deletions(-)
pgsql: Improve error detection capability in proclists.
Improve error detection capability in proclists. Previously, although the initial state of a proclist_node is expected to be next == prev == 0, proclist_delete_offset would reset nodes to next == prev == INVALID_PGPROCNO when removing them from a list. This is the same state that a node in a singleton list has, so that it's impossible to distinguish not-in-a-list from in-a-list. Change proclist_delete_offset to reset removed nodes to next == prev == 0, making it possible to distinguish those cases, and then add Asserts to the list add and delete functions that the supplied node isn't or is in a list at entry. Also tighten assertions about the node being in the particular list (not some other one) where it is possible to check that in O(1) time. In ConditionVariablePrepareToSleep, since we don't expect the process's cvWaitLink to already be in a list, remove the more-or-less-useless proclist_contains check; we'd rather have proclist_push_tail's new assertion fire if that happens. Improve various comments related to proclists, too. Patch by me, reviewed by Thomas Munro. This isn't back-patchable, since there could theoretically be inlined copies of proclist_delete_offset in third-party modules. But it's only improving debuggability anyway. Discussion: https://postgr.es/m/CAEepm=0nwkehyw7ndousf8juukoprncyy3vuasvhrewsota...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ea8e1bbc538444d373cf712a0f5188c906b71a9d Modified Files -- src/backend/storage/lmgr/condition_variable.c | 3 +- src/include/storage/proclist.h| 55 --- src/include/storage/proclist_types.h | 12 -- 3 files changed, 43 insertions(+), 27 deletions(-)
pgsql: pg_upgrade: prevent check on live cluster from generating error
pg_upgrade: prevent check on live cluster from generating error Previously an inaccurate but harmless error was generated when running --check on a live server before reporting the servers as compatible. The fix is to split error reporting and exit control in the exec_prog() API. Reported-by: Daniel Westermann Backpatch-through: 10 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1776c817c7ef452fb47d915d1b550cd73a318944 Modified Files -- src/bin/pg_upgrade/dump.c | 2 +- src/bin/pg_upgrade/exec.c | 14 ++ src/bin/pg_upgrade/parallel.c | 9 - src/bin/pg_upgrade/pg_upgrade.c | 24 src/bin/pg_upgrade/pg_upgrade.h | 6 +++--- src/bin/pg_upgrade/server.c | 18 +- 6 files changed, 35 insertions(+), 38 deletions(-)
pgsql: pg_upgrade: prevent check on live cluster from generating error
pg_upgrade: prevent check on live cluster from generating error Previously an inaccurate but harmless error was generated when running --check on a live server before reporting the servers as compatible. The fix is to split error reporting and exit control in the exec_prog() API. Reported-by: Daniel Westermann Backpatch-through: 10 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d25ee30031b08ad1348a090914c2af6bc640a832 Modified Files -- src/bin/pg_upgrade/dump.c | 2 +- src/bin/pg_upgrade/exec.c | 14 ++ src/bin/pg_upgrade/parallel.c | 9 - src/bin/pg_upgrade/pg_upgrade.c | 24 src/bin/pg_upgrade/pg_upgrade.h | 6 +++--- src/bin/pg_upgrade/server.c | 18 +- 6 files changed, 35 insertions(+), 38 deletions(-)
