From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Random crud left behind by aborted TAP tests |
Date: | 2015-12-04 16:59:26 |
Message-ID: | 9068.1449248366@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Hmm ... I would have supposed that this directory should have been
>> removed by File::Temp's END block. Are END blocks abandoned completely
>> when a signal is received? That seems pretty surprising.
> Yes, they are. Quoth man perlmod:
> An "END" code block is executed as late as possible, that is,
> after perl has finished running the program and just before
> the interpreter is being exited, even if it is exiting as a
> result of a die() function. (But not if it's morphing into
> another program via "exec", or being blown out of the water
> by a signal--you have to trap that yourself (if you can).)
> One option is to install a signal handler somewhere to clean this up.
> Perhaps we can just set $SIG{INT} to a function that calls "die" or
> something like that. But this doesn't solve the problem if the system
> crashes while a test is running, for instance, so perhaps your idea of
> moving these directories to inside tmp_check/ is good.
A second signal received while we're trying to respond to the first
would break it too. (What I was actually doing was strace'ing the whole
process, which would've slowed things down enough that that wouldn't
be an unlikely thing ...)
Let's just put the cruft in tmp_check/ and call it good.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Geoff Winkless | 2015-12-04 17:00:15 | Re: Remaining 9.5 open items |
Previous Message | Alvaro Herrera | 2015-12-04 16:46:54 | Re: Random crud left behind by aborted TAP tests |