Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND
Date: 2019-05-16 02:19:03
Message-ID: 20190516021903.GB1415@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, May 16, 2019 at 10:38:08AM +0900, Michael Paquier wrote:
> So my bet is that the coverage is from pg_ctl/t/004_logrotate.pl,
> which is a test skipped on Windows. culicidae runs that, so the fact
> that the failure got undetected is actually a bit of a mystery because
> this uses sysv_shmem.c.
>
> Except culicidae, I am seeing no members using EXEC_BACKEND which
> enable the syslogger and use TAP tests :(

Oh, actually culicidae catches the failure, but that's burried in the
logs, and I am not able to catch up that on my machine in the TAP
tests:
TRAP: FailedAssertion("!(UsedShmemSegAddr != ((void *)0))", File:
"pg_shmem.c", Line: 848)
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=culicidae&dt=2019-05-16%2000%3A30%3A04&stg=pg_ctl-check

We definitely need to improve that.

Also, I am noticing another consequence as the handling of backend
variable files also suffers consequences:
could not open backend variables file
"pgsql_tmp/pgsql_tmp.backend_var.21912.1": No such file or directory

So it seems that reverting 57431a91 is an option on the table?
Opinions?
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2019-05-16 02:52:31 Re: inconsistent results querying table partitioned by date
Previous Message Amit Langote 2019-05-16 01:51:05 Re: inconsistent results querying table partitioned by date