Alvaro, Thanks again for your review. I went through your proposed patch diffs and applied most of them to my original changes. I did a few things slightly differently since I wanted to keep to to 80 columns for the source code, but I can revisit that if it is not an issue. I also cleaned up the confusing wording around "allocating blocks". I ran a clean build and make check passes. The new patch is attached.
Thanks, Jerry On Wed, Feb 27, 2019 at 4:12 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > On 2019-Feb-05, Jerry Jelinek wrote: > > > First, since last fall, we have found another performance problem related > > to initializing WAL files. I've described this issue in more detail > below, > > but in order to handle this new problem, I decided to generalize the > patch > > so the tunable refers to running on a Copy-On-Write filesystem instead of > > just being specific to WAL recycling. Specifically, I renamed the GUC > > tunable from 'wal_recycle' to 'wal_cow_fs'. Hopefully this will make it > > more obvious what is being tuned and will also be more flexible if there > > are other problems in the future which are related to running on a COW > > filesystem. I'm happy to choose a different name for the tunable if > people > > don't like 'wal_cow_fs'. > > I think the idea of it being a generic tunable for assorted behavior > changes, rather than specific to WAL recycling, is a good one. I'm > unsure about your proposed name -- maybe "wal_cow_filesystem" is better? > > I'm rewording your doc addition a little bit. Here's my proposal: > > <para> > This parameter should only be set to <literal>on</literal> when > the WAL > resides on a <firstterm>Copy-On-Write</firstterm> > (<acronym>COW</acronym>) > filesystem. > Enabling this option adjusts behavior to take advantage of the > filesystem characteristics (for example, recycling WAL files and > zero-filling new WAL files are disabled). > > This part sounds good enough to me -- further suggestions welcome. > > I'm less sure about this phrase: > > This setting is only appropriate for filesystems which > allocate new disk blocks on every write. > > Is "... which allocate new disk blocks on every write" a technique > distinct from CoW itself? I'm confused as to what it means, or how can > the user tell whether they are on such a filesystem. > > Obviously you're thinking that ZFS is such a filesystem and everybody > who has pg_wal on ZFS should enable this option. What about, say, Btrfs > -- should they turn this option on? Browsing the wikipedia, I find that > Windows has this ReFS thing that apparently is also CoW, but NTFS isn't. > I don't think either Btrfs or ReFS are realistic options to put pg_wal > on, so let's just list the common filesystems for which users are > supposed to enable this option ... which I think nowadays is just ZFS. > All in all, I would replace this phrase with something like: "This > setting should be enabled when pg_wal resides on a ZFS filesystem or > similar." That should be weasely enough that it's clear that we expect > users to do the homework when on unusual systems, while actively pointing > out the most common use case. > > > Finally, the patch now includes bypassing the zero-fill for new WAL files > > when wal_cow_fs is true. > > That makes sense. I think all these benchmarks Tomas Vondra run are not > valid anymore ... > > The attached v2 has assorted cosmetic cleanups. If you can validate it, > I would appreciate it. > > -- > Álvaro Herrera https://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
0001-cow-filesystem.patch
Description: Binary data
