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
Hi,
This patch removes two temporary files that are not removed. In
Debian, repeated builds fail. We do not allow builds from modified
sources.
The first file was clearly an oversight. It was created separately. I
am not sure why the loop over @keys did not remove the second.
For the record, the
