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>
 <a32a7f28-570c-24a2-aa2a-9f7c96abd88b@enterprisedb.com>
 <54663718-1d87-46f2-a27b-e7edacbfae0d@www.fastmail.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
Message-ID: <1ec33f3d-ea4c-28c8-502c-3eb0a008a6ac@enterprisedb.com>
Date: Thu, 18 Mar 2021 21:51:11 +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: <54663718-1d87-46f2-a27b-e7edacbfae0d@www.fastmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/1ec33f3d-ea4c-28c8-502c-3eb0a008a6ac%40enterprisedb.com>
Precedence: bulk


On 3/18/21 9:06 PM, Euler Taveira wrote:
> On Thu, Mar 18, 2021, at 4:20 PM, Tomas Vondra wrote:
>> I think a better way to test this would be to use a tuple lock:
> I predicated such issues with this test. Your suggestion works for me. Maybe
> you should use less rows in the session 2 query.
> 
>> 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.
> Your suggestion works for me. Maybe you could use less rows in the session 2
> query. I experimented with 1k rows and it generates a temporary file.
> 

OK. Can you prepare a patch with the proposed test approach?

FWIW I can reproduce this on a 32-bit ARM system (rpi4), where 500 rows
simply does not use a temp file, and with 1000 rows it works fine. On
the x86_64 the temp file is created even with 500 rows. So there clearly
is some platform dependency, not sure if it's due to 32/64 bits,
alignment or something else. In any case, the 500 rows seems to be just
on the threshold.

We need to do both - stop using the timing and increase the number of
rows, to consistently get temp files.


regards

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