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
