Re: cleanup temporary files after crash - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: cleanup temporary files after crash
Date
Msg-id 822e3a60-56a1-219d-c473-365751c3e108@enterprisedb.com
Whole thread Raw
In response to Re: cleanup temporary files after crash  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: cleanup temporary files after crash  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
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 ...


regards

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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Key management with tests
Next
From: John Naylor
Date:
Subject: Re: Perform COPY FROM encoding conversions in larger chunks