On Thu, Mar 27, 2025 at 2:28 PM Robert Treat wrote:
> On Thu, Mar 27, 2025 at 12:06 PM David G. Johnston
> wrote:
> >
> > Version 2 Attached
> >
> > -This option specifies the directory where the write-ahead log
> > -should be stored.
> > +This option specifies the direct
On Wed, 2025-03-19 at 15:03 +0100, David Fiedler wrote:
> I've stumbled across a code that used this condition, resulting in unexpected
> behavior.
> I think it worths a note that catching 0 is not possible and that it
> results in a catch all handler.
> What do you think? Should I post the e
On Thu, Mar 27, 2025 at 12:06 PM David G. Johnston
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 for mo
Version 2 Attached
There being two places now (plus doing it manually) I decided to write this
material in the WAL chapter as opposed to application-specific Notes. A
new section seemed warranted.
I expanded upon the material regarding using different file systems and
disks.
I would like to add
On Thu, Mar 27, 2025, at 8:40 AM, Theodor Herlo wrote:
> Both look great to me! I thought the advantage of having different devices
> is also to easy I/O load. But I guess you have to decide for yourself what is
> the best strategy. For me it was important to know what initdb does with
> ---wal
Both look great to me! I thought the advantage of having different devices is
also to easy I/O load. But I guess you have to decide for yourself what is the
best strategy. For me it was important to know what initdb does with ---waldir.
And this is nicely explained here.
One more little thing,
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 --waldir option turns this subdirectory
> entry
> + into
