Обсуждение: Random crud left behind by aborted TAP tests

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/

nothing added to commit but untracked files present (use "git add" to track)
[postgres@sss1 pgsql]$ ls src/bin/scripts/tmp_testGvBC
archives/  backup/  pgdata/

"make distclean" doesn't get rid of it either; I'll have to remove it
manually.

Judging by the subdirectory names, this is "_basedir" of some PostgresNode
instance.  Should this not have been put inside "tmp_check/" so that
existing make clean/distclean rules could take care of it?
        regards, tom lane

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

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
andjust before      the interpreter is being exited, even if it is exiting as a      result of a die() function.  (But
notif it's morphing into      another program via "exec", or being blown out of the water      by a signal--you have to
trapthat 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

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

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