Re: The real reason why TAP testing isn't ready for prime time - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: The real reason why TAP testing isn't ready for prime time
Date
Msg-id CAB7nPqT7ztxTDWOh-_+uQr8CK9iRkvF0RGWmx_GO_N3QY7cBwQ@mail.gmail.com
Whole thread Raw
In response to Re: The real reason why TAP testing isn't ready for prime time  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: The real reason why TAP testing isn't ready for prime time
List pgsql-hackers
On Sat, Jun 20, 2015 at 6:53 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Sat, Jun 20, 2015 at 12:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> On 2015-06-19 11:16:18 -0400, Robert Haas wrote:
>>>> On Fri, Jun 19, 2015 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>> I wonder whether it's such a good idea for the postmaster to give
>>>>> up waiting before all children are gone (postmaster.c:1722 in HEAD).
>>
>>>> I doubt it.
>>
>>> Seconded. It's pretty bad to possibly not be able to start again after
>>> stopping it. I don't see the benefit in not waiting - sure, the
>>> poastmaster exits faster, but postgres hasn't shut down at that point...
>>
>> Yeah.  I'll see about fixing this.  Hard to be sure if it will fix
>> hamster's issue though.
>
> I have re-enabled the TAP tests in hamster. What happens in the next
> couple of days will be interesting to see.he perl

And, we get a failure:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-06-20%2017%3A59%3A01
I am not sure why buildfarm runs makes it more easily reproducible,
one of the reasons may be the perl scripts run underground.
-- 
Michael



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Is Postgres database server works fine if there is a change in system time?
Next
From: Tom Lane
Date:
Subject: Re: pg_stat_*_columns?