Re: Unportable implementation of background worker start

From: Rémi Zara <remi_zara(at)mac(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, cm(at)enterprisedb(dot)com, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unportable implementation of background worker start
Date: 2017-04-25 05:53:02
Message-ID: BD1DFB1E-DBFC-4F20-9674-522360A3D5C6@mac.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> Le 25 avr. 2017 à 01:47, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :
>
> I wrote:
>> What I'm inclined to do is to revert the pselect change but not the other,
>> to see if that fixes these two animals. If it does, we could look into
>> blacklisting these particular platforms when choosing pselect.
>
> It looks like coypu is going to need manual intervention (ie, kill -9
> on the leftover postmaster) to get unwedged :-(. That's particularly
> disturbing because it implies that ServerLoop isn't iterating at all;
> otherwise, it'd have noticed by now that the buildfarm script deleted
> its data directory out from under it. Even if NetBSD's pselect had
> forgotten to unblock signals, you'd figure it'd time out after a
> minute ... so it's even more broken than that.
>

Hi,

coypu was not stuck (no buildfarm related process running), but failed to clean-up shared memory and semaphores.
I’ve done the clean-up.

Regards,

Rémi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sandeep Thakkar 2017-04-25 05:54:40 Re: Patch - Tcl 8.6 version support for PostgreSQL
Previous Message Michael Paquier 2017-04-25 05:43:58 Re: Concurrent ALTER SEQUENCE RESTART Regression