pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
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: Fri, 19 Mar 2021 03:40:55 +0100
Message-ID: <112f0847-a71a-eec2-e561-2d39dc26127a@enterprisedb.com> (raw)
In-Reply-To: <482a6498-7713-e937-c554-7d235c415fba@enterprisedb.com>
References: <CAH503wDKdYzyq7U-QJqGn=Gm6XmoK+6_6xTJ-Yn5WSvoHLY1Ww@mail.gmail.com>
	<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>
	<1ec33f3d-ea4c-28c8-502c-3eb0a008a6ac@enterprisedb.com>
	<34226249-c5ba-4780-a1bb-f3433d19716e@www.fastmail.com>
	<05d307fc-8391-4091-b279-1b3214658f10@www.fastmail.com>
	<049a2752-fc99-194d-31b2-b15ffa914cd4@enterprisedb.com>
	<a26a35c6-8816-4c2b-91b9-7a428e430a57@www.fastmail.com>
	<482a6498-7713-e937-c554-7d235c415fba@enterprisedb.com>

On 3/19/21 2:21 AM, Tomas Vondra wrote:
> On 3/19/21 1:54 AM, Euler Taveira wrote:
>> On Thu, Mar 18, 2021, at 8:34 PM, Tomas Vondra wrote:
>>> Well, that's better, bit it still does not do the trick on the 32-bit
>>> machine - in that case a 1000 rows with int4 still fit into work_mem, so
>>> the temp file is not created. Per my experiments about 1040 rows are
>>> needed - soooo close ;-) So let's make it 2000.
>> My 32-bit laptop needs some repairs so I blindly chose 1k rows.
>>
> 
> Yeah, it's not immediately obvious how many rows are needed. 2000 would
> be enough, but I just bumped it up to 5000 for good measure.
> 
>>> We might as well check that the temp file actually exists, before
>>> killing the backend. Just to be sure.
>> Do you mean with remove_temp_files_after_crash = on? New version attached.
>>
> 
> On second thought, we don't need that check. I realized the second part
> of the test (checking remove_temp_files_after_crash=off) actually does
> verify that we've created the file, so that should be OK.
> 
> I've pushed the previous version with the 5000 rows. Let's see what
> crake and florican think about this ...
> 

So crake and florican seem to be happy now. Not sure about lapwing yet.

But interestingly enough, prion and curculio got unhappy. They worked
fine with the older test, but now it fails with the "no such file or
directory" message. I wonder what makes them different from the other
x86_64 machines ...


regards

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





view thread (35+ messages)  latest in thread

Message-ID: <112f0847-a71a-eec2-e561-2d39dc26127a@enterprisedb.com>
Permalink:  ../112f0847-a71a-eec2-e561-2d39dc26127a@enterprisedb.com/
Also on:    postgresql.org/message-id/112f0847-a71a-eec2-e561-2d39dc26127a@enterprisedb.com

 · 

reply
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: <112f0847-a71a-eec2-e561-2d39dc26127a@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