On Thu, Mar 27, 2025 at 12:06 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> Version 2 Attached
>
> - This option specifies the directory where the write-ahead log
> - should be stored.
> + This option specifies the directory in which to store write-ahead log files.
> + See <xref linkend="wal-internals-relocation"/> for more information.
To be honest, I think the proposed text is a little verbose, and we
could cut it right here. As an example, we don't go into how the
directory must be empty or chnmod settings for --pgdata. I'd also edit
the pg_basebackup changes to match if it were me.
> + the <option>--waldir</option> option. On an existing, but not running,
> + cluster use operating system commands to move the contents of the
> + <filename>pg_wal</filename> directory to the new location, remove the
> + empty directory, and create the symbolic link named <filename>pg_wal</filename>
> + pointing to the new location.
I found this to be awkward to read, and not as significant a warning
as the existing text... perhaps "For an existing cluster, once the
cluster has been shut down, you can use operating system commands... "
> There being two places now (plus doing it manually) I decided to write this material in the WAL chapter as opposed to
application-specificNotes. A new section seemed warranted.
>
+1
> I expanded upon the material regarding using different file systems and disks.
>
> I would like to add a similar "why" to the mount point recommendation but don't know what that would be. Suggestions
welcomed.
>
I'm not sure I follow what you are asking for... but a non-performance
reason to use a seperate mount point for pg_wal, even if the
underlying storage is the same, would be for something like using
filesystem snapshots to grab contents of the data directory without
grabbing wal (which can be handled separately).
Robert Treat
https://xzilla.net
