Thread: 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
Attachment
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