Random crud left behind by aborted TAP tests

Tom Lane wrote:

Yesterday I was fooling around with the TAP tests, and at least once
I changed my mind and control-C'd out of a run. Today I find:

[postgres@sss1 pgsql]$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Untracked files:
(use "git add <file>..." to include in what will be committed)

src/bin/scripts/tmp_testGvBC/

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.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera wrote:

Tom Lane wrote:

Yesterday I was fooling around with the TAP tests, and at least once
I changed my mind and control-C'd out of a run. Today I find:

[postgres@sss1 pgsql]$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Untracked files:
(use "git add <file>..." to include in what will be committed)

src/bin/scripts/tmp_testGvBC/

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.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Dec 5, 2015 at 1:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Let's just put the cruft in tmp_check/ and call it good.

+1. Having those folders with random names showing up when typing git
statue is annoying, so voilà.
-- 
Michael

Michael Paquier <michael.paquier@gmail.com> writes:

On Sat, Dec 5, 2015 at 1:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Let's just put the cruft in tmp_check/ and call it good.

+1. Having those folders with random names showing up when typing git
statue is annoying, so voilà.

Looks good to me, so pushed.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers