On Tue, Jun 30, 2020 at 01:13:39PM +0900, Michael Paquier wrote:
> I looked at the patch, and can confirm that client_wrongperms_tmp.key
> remains around after running 001_ssltests.pl, and client_tmp.key after
> running 002_scram.pl. The way the patch does its cleanup looks fine
> to me, so I'll a
On Mon, Jun 29, 2020 at 03:51:48PM -0400, Tom Lane wrote:
> Daniel Gustafsson writes:
>> That being said, we do retain temporary files on such failures on purpose in
>> our TestLib since 88802e068017bee8cea7a5502a712794e761c7b5 and a few
>> follow-up
>> commits since, should these be handled diff
Daniel Gustafsson writes:
>> On 29 Jun 2020, at 21:27, Tom Lane wrote:
>> Hmm ... so I guess my reaction to both of these is "what guarantees
>> that we get to the part of the script that does the unlinks?".
> That being said, we do retain temporary files on such failures on purpose in
> our Tes
> On 29 Jun 2020, at 21:27, Tom Lane wrote:
> Hmm ... so I guess my reaction to both of these is "what guarantees
> that we get to the part of the script that does the unlinks?".
> I've certainly seen lots of TAP tests fail to complete. Could we
> do the cleanup in an END block or the like? (I'
Daniel Gustafsson writes:
> The proposed patch admittedly seems a bit like a hack, and the client_tmo.key
> handling is wrong as mentioned above. I propose that we instead add the key
> to
> the @keys array and have clean up handle all files uniformly. The attached
> fixes both of the files.
H
> On 29 Jun 2020, at 17:52, Felix Lechner wrote:
> This patch removes two temporary files that are not removed. In
> Debian, repeated builds fail. We do not allow builds from modified
> sources.
Aha, nice catch!
> The first file was clearly an oversight. It was created separately. I
> am not su
