Subject: Re: cleanup temporary files after crash
To: Euler Taveira <euler@eulerto.com>, Thomas Munro <thomas.munro@gmail.com>,
 Michael Paquier <michael@paquier.xyz>
Cc: Euler Taveira <euler.taveira@2ndquadrant.com>,
 Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Tom Lane <tgl@sss.pgh.pa.us>
References: 
 <CAH503wDKdYzyq7U-QJqGn=Gm6XmoK+6_6xTJ-Yn5WSvoHLY1Ww@mail.gmail.com>
 <20201028184252.5vpoe65kcfebbmmf@development>
 <CAH503wCg+yne7hKAAFFHsVPe+tPb-aF5VGaWG0ETqyB3GP=Q+g@mail.gmail.com>
 <20201101012555.GC3000@paquier.xyz>
 <1982ee3c-54c3-280a-806a-fd28ad8f19e6@postgrespro.ru>
 <CAH503wBLgLGhqCduqzOBgCYNS5DiJnUJdU+RVCCQoka8Tndndg@mail.gmail.com>
 <363cb85c-3a03-9a49-b830-8b645c1241d9@enterprisedb.com>
 <YEdqlL3Gr3rZ/aC8@paquier.xyz>
 <CA+hUKGJtZqpMZtYtJZ2cAGfQT5ELEZGKpnK_TjV-fNeB=rYSNw@mail.gmail.com>
 <4245d284-97b2-4056-96c2-455792d9b564@www.fastmail.com>
 <8740f056-a7c0-ff12-0a50-de5324a928ee@enterprisedb.com>
 <822e3a60-56a1-219d-c473-365751c3e108@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
Message-ID: <a32a7f28-570c-24a2-aa2a-9f7c96abd88b@enterprisedb.com>
Date: Thu, 18 Mar 2021 20:20:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <822e3a60-56a1-219d-c473-365751c3e108@enterprisedb.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/a32a7f28-570c-24a2-aa2a-9f7c96abd88b%40enterprisedb.com>
Precedence: bulk

On 3/18/21 6:51 PM, Tomas Vondra wrote:
> Hmm,
> 
> crake and florican seem to have failed because of this commit, with this
> error in the new TAP test:
> 
> error running SQL: 'psql:<stdin>:1: ERROR:  could not open directory
> "base/pgsql_tmp": No such file or directory'
> while running 'psql -XAtq -d port=64336 host=/tmp/sv1WjSvj3P
> dbname='postgres' -f - -v ON_ERROR_STOP=1' with sql 'SELECT COUNT(1)
> FROM pg_ls_dir($$base/pgsql_tmp$$)' at
> /home/andrew/bf/root/HEAD/pgsql.build/../pgsql/src/test/perl/PostgresNode.pm
> line 1572.
> 
> So it seems the pgsql_tmp directory does not exist, for some reason.
> Considering the directory should be created for the first temp file,
> that either means the query in the TAP test does not actually create a
> temp file on those machines, or it gets killed too early.
> 
> The 500 rows used by the test seems fairly low, so maybe those machines
> can do the sort entirely in memory?
> 
> The other option is that the sleep in the TAP test is a bit too short,
> but those machines don't seem to be that slow.
> 
> Anyway, TAP test relying on timing like this may not be the best idea,
> so I wonder how else to test this ...
> 

I think a better way to test this would be to use a tuple lock:

setup:

  create table t (a int unique);

session 1:

  begin;
  insert into t values (1);
  ... keep open ...

session 2:

   begin;
   set work_mem = '64kB';
   insert into t select i from generate_series(1,10000) s(i);
   ... should block ...

Then, once the second session gets waiting on the tuple, kill the
backend. We might as well test that there actually is a temp file first,
and then test that it disappeared.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company