| From: | Nikolay Shaplov <dhyan(at)nataraj(dot)su> | 
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Daniel Gustafsson <daniel(at)yesql(dot)se> | 
| Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> | 
| Subject: | Re: TAP output format in pg_regress | 
| Date: | 2022-11-24 17:07:29 | 
| Message-ID: | 1787166.pFkNfHHBAF@thinkpad-pgpro | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
You guys are really fast... I only think about problem, it is already 
mentioned here... Most issues I've noticed are already fixed before I was able 
to say something. 
Nevertheless...
 /*                                                                              
  * Bailing out is for unrecoverable errors which prevents further testing to    
  * occur and after which the test run should be aborted. By passing non_rec     
  * as true the process will exit with _exit(2) and skipping registered exit     
  * handlers.                                                                    
  */                                                                             
 static void                                                                     
 bail_out(bool non_rec, const char *fmt,...)                                     
 {                                               
In original code, where _exit were called, there were mention about recursion 
(whatever it is) as a reason for using _exit() instead of exit(). Now this 
mention is gone:
-           _exit(2);           /* not exit(), that could be recursive */
+           /* Not using the normal bail() as we want _exit */
+           _bail(_("could not stop postmaster: exit code was %d\n"), r);
The only remaining part of recursion is _rec suffix.
I guess we should keep mention of recursion in comments, and for me _rec 
stands for "record", not "recursion", I will not guess original meaning by 
_rec suffix. I would suggest to change it to _recurs or _recursive to keep 
things clear
-----
+#define _bail(...)	bail_out(true, __VA_ARGS__)
+#define bail(...)	bail_out(false, __VA_ARGS__)
I will never guess what the difference between bail, _bail and bail_out. We 
need really good explanation here, or better to use self-explanatory names 
here... 
I would start bail_out with _ as it is "internal", not used in the code.
And for _bail I would try to find some name that shows it's nature. Like 
bail_in_recursion or something.
-----
+   if (ok || ignore)
    {
-       va_start(ap, fmt);
-       vfprintf(logfile, fmt, ap);
-       va_end(ap);
+       emit_tap_output(TEST_STATUS, "ok %-5i     %s%-*s %8.0f ms%s\n",
+                       testnumber,
+                       (parallel ? PARALLEL_INDENT : ""),
+                       padding, testname,
+                       runtime,
+                       (ignore ? " # SKIP (ignored)" : ""));
+   }
+   else
+   {
+       emit_tap_output(TEST_STATUS, "not ok %-5i %s%-*s %8.0f ms\n",
+                       testnumber,
+                       (parallel ? PARALLEL_INDENT : ""),
+                       padding, testname,
+                       runtime);
    }
This magic spell "...%-5i %s%-*s %8.0f ms\n" is too dark to repeat it even two 
times. I understand problems with spaces... But may be it would be better 
somehow narrow it to one ugly print... Print "ok %-5i    "|"not ok %-5i" to 
buffer first, and then have one "%s%-*s %8.0f ms%s\n" print or something like 
that...
I am not strongly insisting on that, but I feel strong urge to remove code 
duplication here...
-- 
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2022-11-24 17:31:02 | Re: O(n) tasks cause lengthy startups and checkpoints | 
| Previous Message | Simon Riggs | 2022-11-24 16:49:55 | Re: Damage control for planner's get_actual_variable_endpoint() runaway |