Horton

Thread

Commits

  1. Include the process PID in assertion-failure messages.

  1. A modest proposal: let's add PID to assertion failure messages

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-04T21:08:07Z

    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

  2. Re: A modest proposal: let's add PID to assertion failure messages

    Thomas Munro <thomas.munro@gmail.com> — 2020-10-04T21:20:01Z

    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

  3. Re: A modest proposal: let's add PID to assertion failure messages

    Michael Paquier <michael@paquier.xyz> — 2020-10-05T00:58:24Z

    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).
--
Michael

  4. Re: A modest proposal: let's add PID to assertion failure messages

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-05T01:18:24Z

    Michael 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

  5. Re: A modest proposal: let's add PID to assertion failure messages

    Andres Freund <andres@anarazel.de> — 2020-10-06T18:27:48Z

    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