A modest proposal: let's add PID to assertion failure messages
In these days when we run almost all test cases in parallel, it's
frequently not that easy to tie a "TRAP: ..." message in the log
to nearby log messages. (The postmaster's subsequent complaint
often helps, but it could be some distance away in the log; and
good luck untangling things if more than one Assert failure happens
concurrently.) We could add a simple bread crumb trail by
including the process's PID in such messages. Any objections?
regards, tom lane
On Mon, Oct 5, 2020 at 10:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
In these days when we run almost all test cases in parallel, it's
frequently not that easy to tie a "TRAP: ..." message in the log
to nearby log messages. (The postmaster's subsequent complaint
often helps, but it could be some distance away in the log; and
good luck untangling things if more than one Assert failure happens
concurrently.) We could add a simple bread crumb trail by
including the process's PID in such messages. Any objections?
+1
On Mon, Oct 05, 2020 at 10:20:01AM +1300, Thomas Munro wrote:
On Mon, Oct 5, 2020 at 10:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
In these days when we run almost all test cases in parallel, it's
frequently not that easy to tie a "TRAP: ..." message in the log
to nearby log messages. (The postmaster's subsequent complaint
often helps, but it could be some distance away in the log; and
good luck untangling things if more than one Assert failure happens
concurrently.) We could add a simple bread crumb trail by
including the process's PID in such messages. Any objections?+1
+1. (log_line_prefix includes %p in its default configuration for the
TAP tests).
--
MichaelMichael Paquier <michael@paquier.xyz> writes:
+1. (log_line_prefix includes %p in its default configuration for the
TAP tests).
Right, but of course you don't get log_line_prefix on Assert messages.
regards, tom lane
On 2020-10-05 10:20:01 +1300, Thomas Munro wrote:
On Mon, Oct 5, 2020 at 10:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
In these days when we run almost all test cases in parallel, it's
frequently not that easy to tie a "TRAP: ..." message in the log
to nearby log messages. (The postmaster's subsequent complaint
often helps, but it could be some distance away in the log; and
good luck untangling things if more than one Assert failure happens
concurrently.) We could add a simple bread crumb trail by
including the process's PID in such messages. Any objections?+1
+1