Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qehfP-007bIK-5f for pgsql-novice@arkaria.postgresql.org; Fri, 08 Sep 2023 20:01:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qehfM-00CekK-Ss for pgsql-novice@arkaria.postgresql.org; Fri, 08 Sep 2023 20:01:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qehfM-00Cek7-HI for pgsql-novice@lists.postgresql.org; Fri, 08 Sep 2023 20:01:20 +0000 Received: from mail-yw1-x1136.google.com ([2607:f8b0:4864:20::1136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qehfI-003x27-Ru for pgsql-novice@lists.postgresql.org; Fri, 08 Sep 2023 20:01:19 +0000 Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-58d41109351so49095687b3.1 for ; Fri, 08 Sep 2023 13:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694203275; x=1694808075; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vJqEsqHFmBhJRwzaXMF67vC4M95gjtgNlRy8WYhjqcw=; b=iSc/K/NESFYQkOybdUl5gzCuEdiB/AJxbwdAL+iIwjZ1Ud1bf5mvXZD27DVe5ncGXt eVyYLd/VJGqYZZUKbEtKHZX4tuXOuli0ddqq2leBv95gD5NPftixRJ273aXVBKWqBbS3 aTyFM2MiT3aGxW1rPgQWX2TkwY0D1hliTA+dEU1qXzHK2+QsMJ+qBMvOkYdKzM0u8eFB 3o4IE9mKkA9BXgklG6ifZfPIYZChYXQYbeO0jxk25FAsqk2YbYazUvf9gZ7j5II3bx4e X3dZfyyVfGqSRZl5MGC4cqte/stKtffK0BJ0DhX3xGktWl5SIQQknUArqaIjV4p1lwQp rXLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694203275; x=1694808075; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vJqEsqHFmBhJRwzaXMF67vC4M95gjtgNlRy8WYhjqcw=; b=jCpzJZu88xDosfmWFRwC8Q62POqXKbCGAnJz/RFTRo6x2Hvsyrj2AFE6wMO7Q43K10 eEs8IFF+rRVZilNvINHu1NEpKsPmYsIKRfBJ/h4UqRwADs+6pnvtQG2s1roXW2LnP/cM 4W0HUvZxiamjpgfbgJAYzvqXsQpIWLYFilKuc584rbOoZctC2f1w0+6m1RZLSj3FUmhI GocUIJR4OnwGn5BUT2lyPzJsZOlupnfupWJKvm6yzY+64B2gDp14XSXasxxUgxZr9y0U YfRLWG9pVwb891lGUpIWp7z0x/FNkh7twDC78wP3JdvU1PIiERw64d5ExDI+a6kmOpKt CLoA== X-Gm-Message-State: AOJu0YyL4LecoAsacjta2ak3yhnRPeAoG8aOv1cLlKemELQGX0eBlCbz MPwQvdJZFa2ag6gvaIb0F66DsVkhrlKD0EuM7tg= X-Google-Smtp-Source: AGHT+IEA1UA/T9IqJWepjuWbiovfg4xXObapneROzrHcXAeOaXmy5V/wLV7f+ztIDk3x876oxMLWagTqY778a0Apb4I= X-Received: by 2002:a25:e0c7:0:b0:d7b:9b9b:2fc3 with SMTP id x190-20020a25e0c7000000b00d7b9b9b2fc3mr8734310ybg.3.1694203274950; Fri, 08 Sep 2023 13:01:14 -0700 (PDT) MIME-Version: 1.0 References: <5520a74bc59f5aed4b29772b04c28d58566013a2.camel@cybertec.at> In-Reply-To: <5520a74bc59f5aed4b29772b04c28d58566013a2.camel@cybertec.at> From: bruno da silva Date: Fri, 8 Sep 2023 16:01:03 -0400 Message-ID: Subject: Re: Even if I have a lot of free space PgSQL returns "ERROR: could not extend file - No space left on device" To: Laurenz Albe Cc: Nature Conservation Geovista Space , pgsql-novice@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000617de10604de70a3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000617de10604de70a3 Content-Type: text/plain; charset="UTF-8" Hello. Does temp_file_limt also applies to reindex? Thanks On Fri, Sept 8, 2023, 3:54 p.m. Laurenz Albe wrote: > On Fri, 2023-09-08 at 12:22 +0100, Nature Conservation Geovista Space > wrote: > > After hours running a query to Subdivide, I get this Postgres error > > > > > > 2023-09-08 02:11:23.745 BST [328594] postgres@database ERROR: could > not extend file "base/16388/7985375.1020": No space left on device > > > 2023-09-08 02:11:23.745 BST [328594] postgres@database HINT: Check > free disk space. > > > > > > 2023-09-08 02:11:23.745 BST [328594] postgres@database STATEMENT: > CREATE TABLE _gaul_administrative_subdivided100 AS ( > > > SELECT *, st_subdivide(geom,100) AS geom_subdivided100 > > > FROM gaul_administrative > > > ); > > > > It seems that it is not a problem of space. [df shows there is space > everywhere] > > "After running a query for hours" makes it appear like you run out of disk > space with > temporary files. These only exist during the lifetime of the query, so > they are gone again after > the statement has failed. > > Set "temp_file_limit" to avoid that kind of problem. > > Yours, > Laurenz Albe > > > --000000000000617de10604de70a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello. Does temp_file_limt also applies to reindex?

Thanks

On Fri, Sept 8, 2023, 3= :54 p.m. Laurenz Albe <laure= nz.albe@cybertec.at> wrote:
= On Fri, 2023-09-08 at 12:22 +0100, Nature Conservation Geovista Space wrote= :
> After hours running a query to Subdivide, I get this Postgres error > > =C2=A0
> > 2023-09-08 02:11:23.745 BST [328594] postgres@database ERROR:=C2= =A0 could not extend file "base/16388/7985375.1020": No space lef= t on device
> > 2023-09-08 02:11:23.745 BST [328594] postgres@database HINT:=C2= =A0 Check free disk space.
> > =C2=A0
> > 2023-09-08 02:11:23.745 BST [328594] postgres@database=C2=A0 STAT= EMENT:=C2=A0 CREATE TABLE _gaul_administrative_subdivided100 AS (
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 SELECT *, st_subdivide(geom,100) AS geom_subdiv= ided100
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= FROM gaul_administrative
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );
>
> It seems that it is not a problem of space. [df shows there is space e= verywhere]

"After running a query for hours" makes it appear like you run ou= t of disk space with
temporary files.=C2=A0 These only exist during the lifetime of the query, s= o they are gone again after
the statement has failed.

Set "temp_file_limit" to avoid that kind of problem.

Yours,
Laurenz Albe


--000000000000617de10604de70a3--