On Mon, Apr 01, 2019 at 08:19:56AM +0000, Daniel Gustafsson wrote: > On Monday, April 1, 2019 12:42 AM, Noah Misch <n...@leadboat.com> wrote: > > On Fri, Mar 29, 2019 at 09:53:51AM +0000, Daniel Gustafsson wrote: > > > > This seems like a case where it would be useful to log a shmdt() error or > > > do > > > an Assert() around the success of the operation perhaps? > > > > I'll add the same elog(LOG) we have at other shmdt() sites. I can't think of > > a site where we Assert() about the results of a system call. While shmdt() > > might be a justified exception, elog(LOG) seems reasonable. > > Agreed, seems reasonable.
Pushed, but that broke two buildfarm members: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2019-04-04%2000%3A33%3A14 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=komodoensis&dt=2019-04-04%2000%3A33%3A13 I think the problem arose because these animals run on the same machine, and their test execution was synchronized to the second. Two copies of the new test ran concurrently. It doesn't tolerate that, owing to expectations about which shared memory keys are in use. My initial thought is to fix this by having a third postmaster that runs throughout the test and represents ownership of a given port. If that postmaster gets something other than the first shm key pertaining to its port, switch ports and try again. I'll also include fixes for the warnings Andres reported on the pgsql-committers thread.