Re: cleanup temporary files after crash

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