From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Euler Taveira <euler@eulerto.com>
To: Thomas Munro <thomas.munro@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Euler Taveira <euler.taveira@2ndquadrant.com>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: cleanup temporary files after crash
Date: Thu, 18 Mar 2021 20:20:08 +0100
Message-ID: <a32a7f28-570c-24a2-aa2a-9f7c96abd88b@enterprisedb.com> (raw)
In-Reply-To: <822e3a60-56a1-219d-c473-365751c3e108@enterprisedb.com>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@enterprisedb.com, euler@eulerto.com, thomas.munro@gmail.com, michael@paquier.xyz, euler.taveira@2ndquadrant.com, a.lubennikova@postgrespro.ru, tomas.vondra@2ndquadrant.com, pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
Subject: Re: cleanup temporary files after crash
In-Reply-To: <a32a7f28-570c-24a2-aa2a-9f7c96abd88b@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox