Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k0b2D-0001mp-Ja for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Jul 2020 01:37:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k0b2C-0000Jr-25 for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Jul 2020 01:37:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k0b2B-0000Jj-O5 for pgsql-hackers@lists.postgresql.org; Wed, 29 Jul 2020 01:37:31 +0000 Received: from mail-il1-x143.google.com ([2607:f8b0:4864:20::143]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k0b28-00083a-5A for pgsql-hackers@postgresql.org; Wed, 29 Jul 2020 01:37:31 +0000 Received: by mail-il1-x143.google.com with SMTP id b18so12790920ilo.12 for ; Tue, 28 Jul 2020 18:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Dy/AD5X2Lq4ce2YFo/zCmdwFx2Flty/svaCvTaiJlg4=; b=VfrJxlKnTNEwGve+bdXxsU0v7ZRKbvPGzX52Z4ohPrAvUg71rYNkVd2qkX6Ej8WzrH U9yFpBPRVB8Ob1oQxTJ6xHf54rScNdpHhAJpVKGrZUiNoraJes5MHNYXsYXGr1LKBcoU oLD2dNXo17sIayQBPucHMk0KZr+ql5QIaE0YR/+Rv5N3vPWwez0oezLxcEV0SAV1J4vm BoVwd1QtTWrdzfId9uzCqwhBmeZxH3me5/aX0Adhb9OlqVsFtEOgBcd4hgIgdYMcvau2 0JYxUico8vhTIrBwiAXhu+CMC6si/JwEHRKiLj6QviuLieK2c19daIXbHW1dTdljZFE+ +iEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Dy/AD5X2Lq4ce2YFo/zCmdwFx2Flty/svaCvTaiJlg4=; b=kGG4lu11dSTVUJPF1whse+3G2Dv75ye3t4mKRI7UfcgxLZ4qjJslu2UoSr5JF2vGGO 5/4oezEkGn3hvEVLQrXhU9rkblTn2QsuY+wm/xBvBq4/ls9bMcOk6Fpru2afCMRWbUEl J+4sVEo9Xs9ckInawyUReeZn/9WnbVRYAPnnHPXTUxawRQRPOvd/PSyl2h1iibl2wIR/ teReeEYFU9GTQ13eh144zYFHJkKTBGmJHQJvvt8LnkJPcGpnrSafirkcPc2jhoj57F4l YQFLZcen9GqjCnY60ojp4sg04+rZ+gGS7Jbbu3ivld+40buSAjMQd2JRTgzBys7Eto0g 32Bg== X-Gm-Message-State: AOAM531ZwOataOJFs4Ns1G6QtRNxphrZOlvlV7FeRLIo0ISMehNWIC+L 13ZIk+INpQQg8Vyf/fW825gVZg== X-Google-Smtp-Source: ABdhPJwZMPBX4Gho6wPgnAFX9u5OYWjsEPmSZPAFK3P6BVxNT+PP5YLiTcYJEQ66md5e6g8ESI1RLA== X-Received: by 2002:a92:dc8c:: with SMTP id c12mr31871639iln.243.1595986646614; Tue, 28 Jul 2020 18:37:26 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id b2sm340347ilf.0.2020.07.28.18.37.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 18:37:25 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 40718800171; Tue, 28 Jul 2020 20:37:24 -0500 (CDT) Date: Tue, 28 Jul 2020 20:37:24 -0500 From: Justin Pryzby To: Thomas Munro Cc: pgsql-hackers , "Bossart, Nathan" Subject: Re: shared tempfile was not removed on statement_timeout Message-ID: <20200729013724.GM20393@telsasoft.com> References: <20200721043258.GE5748@telsasoft.com> <20200727103902.GM4286@telsasoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: <20200727103902.GM4286@telsasoft.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 27, 2020 at 05:39:02AM -0500, Justin Pryzby wrote: > On Mon, Jul 27, 2020 at 08:00:46PM +1200, Thomas Munro wrote: > > Why can't tuplesort_end do it? > > Because then I think the parallel workers remove their own files, with tests > failing like: > > +ERROR: could not open temporary file "0.0" from BufFile "0": No such file or directory > > I look around a bit more and came up with this, which works, but I don't know > enough to say if it's right. I convinced myself this is right, since state->nParticipants==-1 for workers. Only the leader should do the cleanup. Added here: https://commitfest.postgresql.org/29/2657/ -- Justin --St7VIuEGZ6dlpu13 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-explicity-remove-shared-fileset.patch" From 3d9db664d86f9a1f4745c19d1fb620dae5f9e42a Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Mon, 27 Jul 2020 05:50:34 -0500 Subject: [PATCH v1] explicity remove shared fileset.. ..to avoid leaving it around if a timeout occurs *during* the path that would normally release resources. Discussion: https://www.postgresql.org/message-id/20191212180506.GR2082%40telsasoft.com Analysis: Thomas Munro --- src/backend/utils/sort/tuplesort.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c index 3c49476483..b2b3ff789c 100644 --- a/src/backend/utils/sort/tuplesort.c +++ b/src/backend/utils/sort/tuplesort.c @@ -1387,6 +1387,15 @@ tuplesort_free(Tuplesortstate *state) void tuplesort_end(Tuplesortstate *state) { + /* + * Leader explicitly cleans up shared filesets. + * This would normally be cleaned up by DestroyParallelContext(), but + * doing it now avoids leaving files behind if an error/timeout happens + * *during* cleanup. + */ + if (state->shared && state->shared->workersFinished == state->nParticipants) + SharedFileSetDeleteAll(&state->shared->fileset); + tuplesort_free(state); /* -- 2.17.0 --St7VIuEGZ6dlpu13--