Re: [HACKERS] Random crud left behind by aborted TAP tests
Michael Paquier writes: > On Sat, Dec 5, 2015 at 1:59 AM, Tom Lane 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
Re: [HACKERS] Random crud left behind by aborted TAP tests
On Sat, Dec 5, 2015 at 1:59 AM, Tom Lane 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 20151205_tap_tempdirs.patch Description: binary/octet-stream -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Random crud left behind by aborted TAP tests
Alvaro Herrera 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
Re: [HACKERS] Random crud left behind by aborted TAP tests
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 ..." 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 Herrerahttp://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
Re: [HACKERS] 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 ..." 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 Herrerahttp://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
