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 1sl7GB-005Jkh-Ju for pgsql-admin@arkaria.postgresql.org; Mon, 02 Sep 2024 13:38:24 +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 1sl7GA-00ESYI-Id for pgsql-admin@arkaria.postgresql.org; Mon, 02 Sep 2024 13:38:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sl7GA-00ESWV-7J for pgsql-admin@lists.postgresql.org; Mon, 02 Sep 2024 13:38:22 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sl7G7-000IKN-Uc for pgsql-admin@lists.postgresql.org; Mon, 02 Sep 2024 13:38:21 +0000 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a8a1d78e7b0so8401966b.3 for ; Mon, 02 Sep 2024 06:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1725284298; x=1725889098; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=zC290feScjzeKU5ki4EchA5INqi+Jr2lOyIaGMJln0A=; b=Xn2mIvMMVmGn5LC2v3KJXoz4gTxKpQ+uqm0vDzt1aKAQG8GKFpMx4HLmk34XSnrVR+ wMUEZz/3BJjOi25TKsmjE2LN1xoGS0yRoFhfNDqwRqGlmnn5R6mzNE7+UNJneWMZdRuN W84Y85C68uFDnHSSBBklOLQl4RKfbQzNbkLNT04peO3vucGUv1OMUifh8u4C58Deam7s /li0B+QRZLQOpve7def8nabS341Tw2iNvxPTvW1jVHP2Cjs2ifuPGWGv/CJsajY5nRWa ZGigaxvqzzL03oY5YgfhHbsa/R8/7us90Tbj3tzmyx2ybth1tt6bfvPr7lxO5Xtl0b7W +Egw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725284298; x=1725889098; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zC290feScjzeKU5ki4EchA5INqi+Jr2lOyIaGMJln0A=; b=kb7p7kFjLXotvEX3SUxE4mZVprUEPcyn2Gd5oj6O+MVtXF611RUHUA04jYsKY4Xstk 2xbhB4me9WmM5uedR9a+fboOKCbzngUdxe/uya9GnVoU5S0FWAjarEcQQhv4Xfi+EJnj BXUpp0AKK1lxzDFtaiLHtPdGT0iCFiw/Op/Yijq+eAW07jULy0X5/uEOESo73FcdBWhQ IOUSzqbd4mIWluubSSUcoCI+WS5tC+uLNxphyskQRYNHhs6yWmI2PpQu9Q0Veh5V0PZS ZrQCoIL6WZICWcxV4tH4y0QleMpOLEaxeAaQHCZERux6EAFVwppG4R3lGZUBUOhhAyTV rRMw== X-Forwarded-Encrypted: i=1; AJvYcCVUqcH2nZKAc/gmbvVx3RfHD23WBaK0xNlxhf30+G/Nlt/+/bxSnxnBuZELAFkz6VTXRpRmjx5uz+jYhQ==@lists.postgresql.org X-Gm-Message-State: AOJu0Yzjo8nsGn7asrp5957+IMkJEjyq2pYKnBXaqpxHsNs6rbNPGjV6 5TukWlGV3tEP/bcOseGj2wFaPiQ54iG/dIvNNeh85QXQaCG/5/4Dx5GQfKHCIjfZwrVwwxVGddN 4 X-Google-Smtp-Source: AGHT+IGkMMfgi8i6Q2n1fMfcO7wUwFfojsHjDhPjEYQD7OKKKg4hWVxUcJhlwHMWfQhysCV12ClFYw== X-Received: by 2002:a17:906:ee85:b0:a86:8ff6:6d2d with SMTP id a640c23a62f3a-a89fae1b715mr301097166b.37.1725284297808; Mon, 02 Sep 2024 06:38:17 -0700 (PDT) Received: from dynamic-pd01.res.v6.highway.a1.net ([2001:871:5e:53f4:c624:8ff4:8180:8ef6]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8989021973sm556976666b.82.2024.09.02.06.38.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Sep 2024 06:38:17 -0700 (PDT) Message-ID: Subject: Re: Postgresql Database and PG_WAL locations From: Laurenz Albe To: Ron Johnson , Pgsql-admin Date: Mon, 02 Sep 2024 15:38:17 +0200 In-Reply-To: References: <5BDE97CE-242C-479A-BDC7-CF263BBD554B@gmail.com> <2fba534e999d3233dc4fe43aabf84622f93064eb.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.4 (3.52.4-1.fc40) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2024-09-02 at 09:15 -0400, Ron Johnson wrote: > > but it is still a good idea to separate data and WAL, > > so that they cannot fill up each other's file system. >=20 > Regular checkpoints, transactions(*) that don't stay open for hours > or days, and monitoring replication to ensure that it keeps replicating > data instead of piling up on the primary server all solve that problem Right, if everything is working as it should, monitoring is in place etc. this will never happen. But I believe that paranoia is a virtue for the DBA, and it is better to have a second line of defense than a crash of the database. > Honestly... it's been YEARS=C2=A0since I've seen that problem. I see it all the time (on systems I didn't set up). Yours, Laurenz Albe