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 1txkXB-00E7k6-E6 for pgsql-docs@arkaria.postgresql.org; Thu, 27 Mar 2025 10:32:25 +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 1txkX9-003p1V-85 for pgsql-docs@arkaria.postgresql.org; Thu, 27 Mar 2025 10:32:23 +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 1txkX8-003p1N-QB for pgsql-docs@lists.postgresql.org; Thu, 27 Mar 2025 10:32:22 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1txkX6-001Pef-2F for pgsql-docs@lists.postgresql.org; Thu, 27 Mar 2025 10:32:21 +0000 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-ac34257295dso152541466b.2 for ; Thu, 27 Mar 2025 03:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1743071539; x=1743676339; 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=bsyy6TuOfKfe046uTW5mdOxlCo4Y3PNT7soH6W0YMzY=; b=JcyRFTHDFp/r0djkYjBtvWg/yk3z5hVTGATGPBYfCmPvPDDTkZ3NhYbdpOI9THlJYv L8BGRfbsiwbRnyT/fndk3eBXJ1eOoHD0w+T58wN31UIZj58AAL7V8mgKZGG6cJeG8VID czKeFTdUKfYPrZ5ZmJXoo/oG7LDGw53MzQRXlUBQCdg5l0rmeEoT6RufXn3CBxDdxOIf d2siCUmwBewywv6HTKq03Y9W/JvEnDOH+9bIXqpIoFW41YuVpLfYATPVC9V+7ef3q+02 VqCbd7mrObxAI06HnIqZ8Esv1uBjcdlNvbUhGfFysZSVsrYJRmJDXfNtDHF6Spea6KcT 5eWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743071539; x=1743676339; 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=bsyy6TuOfKfe046uTW5mdOxlCo4Y3PNT7soH6W0YMzY=; b=XBzKUq21YAEqFt7VEA/9JXCO9Waj2OtppbGDJcL2medwco6GKE7s7R9VNWPEYkzaKn YynTToU3YGAgJ9XDFzCM8m+4NYdn5gCKXHAycDSCsPeI52PFveJL7OyjS7J01LYNbqbJ b/UT69F8F5s84ArcIC54whssGfAL/ptHlAjkhA6AA5IHnwNZK/B5LlZq1tWMX4Rqy8cA DsFrkaqSmhNgp/jp7PRx+7gMXHvpxdJIs0YVkbXUrEPpdsnAmMA4kW9ztlJt51NKdn9v mrMRcqHVDh2Ue/9BHcod5ompCQNUmAPFeSHAll4czwaSbS6FMIl/n7bRR+ZHAB+Zd4Fo bTmw== X-Forwarded-Encrypted: i=1; AJvYcCVaSt6ja5CTz7FT8eSrdct+J2f2jWKxFNBQXNjkD8oI4aJBBtqtKAXt9XWZuYRdPglsfZTfG5QHkg9C@lists.postgresql.org X-Gm-Message-State: AOJu0Yw7mW5XHG//gE+hSIpobxrbTdo+x5KDp7P7VzBISia9GUFJ5dY9 heXpwSfhIMyALVcWFQyPY4kfbyVDOKH15FiVC/+h+9xiFRrsZoq9rbZvNTeIRNtiiwK8mjJ8A3g DQD0= X-Gm-Gg: ASbGnctFv8MCgQ8uvWuCHwf8jpIgVLrPlAlr/NqjV+NwGL8MPmLLVe4OQjCQEn1E5vf WezhoYc8slvmSJIev6o7gCpyJ/3rJ+ybcS+0JhUQT9f3IdvZsViZr6R82EghmRP+5LttAbP06XR Uo0ZSeYRgBG7VNQHCGHP/u7T5DY60i4+RgRsFN2+6s8bMm2J3sOSEDa4Yzx9O3yPiWIebxlHQ3z CS9LDLKr6pMQ5lh4JSMbjkbx9rldmiR1QV1UeaN5ji7NIn39an9oR+23m289s1wY9Blh+j2sPLK NG+kK4Vbzm2Morq6Io13aDa9HQv3SVw64/IqrBv9Za5r2wnqU8TxRbwknDD/Q1w= X-Google-Smtp-Source: AGHT+IGEMYp/473JbXUddOiqfWL5rtRRe6dhcy9ty1szPZSXANd/NdqOeKYOSIzEpnsdi19BUFLg5Q== X-Received: by 2002:a17:907:3da1:b0:ac2:6bb5:413c with SMTP id a640c23a62f3a-ac6faf45fbcmr260763466b.31.1743071539004; Thu, 27 Mar 2025 03:32:19 -0700 (PDT) Received: from localhost.localdomain ([2001:871:5e:66dc:fd6:68ea:9d3:c178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac6932e843asm782095866b.83.2025.03.27.03.32.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Mar 2025 03:32:18 -0700 (PDT) Message-ID: <1f38ffb000b9ead35702a63191c28f36e259c7d1.camel@cybertec.at> Subject: Re: Documentation for initdb option --waldir From: Laurenz Albe To: "David G. Johnston" , t.herlo@proventa.de, pgsql-docs@lists.postgresql.org Date: Thu, 27 Mar 2025 11:32:18 +0100 In-Reply-To: References: <174291831170.676.262776479364497352@wrigleys.postgresql.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2025-03-26 at 17:34 -0700, David G. Johnston wrote: > + > + The pg_wal subdirectory will always exist within= the > + data directory. This is where PostgreSQL > + sends its write-ahead log (WAL) files. > + Specifying the option turns this subdirecto= ry entry > + into a symbolic link. In general, this is only useful if the remote l= ocation > + is on a different physical device. An existing directory must be emp= ty and > + should not be a mount point. The directory will be created > + (including missing parents) if necessary. > + I think that it is very valuable to have WAL on a different file system on = the same storage device. The idea is that growing data files cannot exhaust th= e space available for WAL. How about this: There is always a pg_wal within the data directory= . By default, it is a directory where PostgreSQL places its write-ahead log (WAL) segment files. If you create the WAL location somewhere else using the= option , pg_wal will be created = as a symbolic link pointing to that WAL location. If the directory already exists, it must be empty and should not be a m= ount point. The directory will be created (including missing parents) if ne= cessary. Yours, Laurenz Albe