Date: Wed, 3 Apr 2019 19:05:43 -0700
From: Noah Misch <noah@leadboat.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
	"9erthalion6@gmail.com" <9erthalion6@gmail.com>,
	"sfrost@snowman.net" <sfrost@snowman.net>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid
Message-ID: <20190404020543.GA1319573@rfd.leadboat.com>
References: 
 <CA+q6zcV4r+oS27G-nYqonG+q7442BOA350s3jeRtA-Oqx4vDWg@mail.gmail.com>
 <20181130065140.GB2774301@rfd.leadboat.com>
 <20181203004106.GA2860387@rfd.leadboat.com>
 <20190304.180420.139624607.horiguchi.kyotaro@lab.ntt.co.jp>
 <20190307032422.GB1797215@rfd.leadboat.com>
 <20190309071610.GA2039121@rfd.leadboat.com>
 <GrdLgAdUK9FdyZg8VIcTDKVOkys122ZINEb3CjjoySfGj2KyPiMKTh1zqtRp0TAD7FJ27G-OBB3eplxIB5GhcQH5o8zzGZfp0MuJaXJxVxk=@yesql.se>
 <20190331224233.GC891537@rfd.leadboat.com>
 <eUPnXaH0-lP5UPgJAeBbpVF-9I3A9TzxXyQOAsTBO4jmB1sFTzFs6vSwaRAnHTmoDo0wJ-EtuHeyM0vn1LO0xm6NPc_dR0dwOzg8dJrLqhU=@yesql.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <eUPnXaH0-lP5UPgJAeBbpVF-9I3A9TzxXyQOAsTBO4jmB1sFTzFs6vSwaRAnHTmoDo0wJ-EtuHeyM0vn1LO0xm6NPc_dR0dwOzg8dJrLqhU=@yesql.se>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

On Mon, Apr 01, 2019 at 08:19:56AM +0000, Daniel Gustafsson wrote:
> On Monday, April 1, 2019 12:42 AM, Noah Misch <noah@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.