Here's a new version with some cleanup and documentation. I tried to pare it down to the minimum change for the back-branches, keeping unnecessary changes for master. In the process, I also thought a bit about how to de-confused matters on Windows, where the function we call as ftruncate() behaves differently in a crucial respect. See attached.
I'm proposing to back-patch 0001. 0002 and 0003 are proposals for master only. See below for replies to separate messages from Jakub and Bruce. On Thu, Oct 30, 2025 at 11:14 PM Jakub Wartak <[email protected]> wrote: > +1 to this GUCs as this would also help the nearby thread with XFS > mysteries which are not fully solved [1]. Since the latest message in > that discussion, I'm aware of at least one additional report of XFS > failing at fallocate() with free space too, but without any details > from the OS support vendor why that happened, so this $patch could be > also used to workaround that problem too. Yeah, that seems quite important, and the new report in psql-bugs #19348 sounds like another case. > Just nitpicking: > > > and back-patch it into 17 for the upcoming release. > > It is working as expected on my ZFS system in light testing. Rebasing > > and figuring out where to add the missing documentation for last > > chance review... > > Why just 17? (wasn't fallocate() introduced in 16? 4d330a61bb19 and > 31966b151e6ab are from Apr 2023, while 16 was released on Sep 2023) Right, fixed. > From other things, I was wondering about this: > > > PGC_USERSET > > QQ: Do we really want to have those two GUCs to be alterable like that > by anyone? The alternative would be like let's say PGC_SIGHUP? (on one > end it's flexible, but are there any downsides to this as it stands > out in 0001?). I've checked others and io_workers is PGC_SIGHUP > (understandable), but we also have io_combine_limit && > effective_io_concurrency with PGC_USERSET. I'm just wondering if it > would be sane to have one backend doing I/O with fallocate() and other > just writing using pwrite(). One could argue you could be writing to > two different filesystems with two different users... Yeah. Let's go with PGC_SIGHUP. Let's worry about multiple filesystems when we've figured out how to do per-tablespace settings. This is vapourware for later, but I've been wondering if we could invent a sysctl-style hierarchy as a scoping mechanism, something like: tablespace.foo.random_page_cost=1 tablespace.foo.file_extend_method=ftruncate tablespace.foo.io_combine_limit=1MB Obviously there are some name resolution problems with that. I also thought about allowing a new kind of configuration file inside tablespace directories, but that doesn't work for PGC_USERSET stuff like random_page_cost. If the hierarchy idea goes somewhere, it might also allow a reorganisation like [tablespace.foo.]io.combine_limit, with legacy long names like io_combine_limit still supported, but that's getting quite far off topic... On Fri, Oct 31, 2025 at 5:59 AM Bruce Momjian <[email protected]> wrote: > Uh, the problem with backpatching new GUCs is that the GUC variable will > _not_ appear in any postgresql.conf file until a new initdb is run. > This can be quite confusing for people. The minor release notes have to > explain this. Yeah. Fortunately the vast majority of users won't ever need to know about this. Those who run into a problem should hopefully find their way to the docs, release notes, settings view, these threads, or write to us? Any other way of controlling this that we invent to avoid back-patching a GUC would surely only be harder to find than a new GUC, I think? And I don't think we're anywhere near the level of needing to revert the posix_fallocate() feature: both reported problems are rare. (Though there is a lesson here in terms of off-switch planning.) Here's my attempt at a release note: "The new setting file_extend_method can be set to write_zeros to disable the use of the posix_fallocate() system call when extending relation files. This is a workaround for users of BTRFS compression, reported to be disabled by posix_fallocate(), and some versions of XFS, reported to fail with spurious ENOSPC errors under some workloads."
From 58ec33550147e324e5a6a8793c8e502b9e7065f2 Mon Sep 17 00:00:00 2001 From: Thomas Munro <[email protected]> Date: Sat, 31 May 2025 22:50:22 +1200 Subject: [PATCH v2 1/3] Add file_extend_method=posix_fallocate,write_zeros. Provide a way to disable the use of posix_fallocate() for relation files. It was introduced by commit 4d330a61bb1. The new setting file_extend_method=write_zeros can be used as a workaround for problems reported from the field: * BTRFS compression is disabled by the use of posix_fallocate() * XFS users have reported a few cases of spurious ENOSPC that haven't been explained yet The default is file_extend_method=posix_fallocate as before. The new mode is simlar to PostgreSQL < 16, except that bulk extension writes zeros for multiple blocks at a time. Backpatch-through: 16 Reviewed-by: Jakub Wartak <[email protected]> Reported-by: Dimitrios Apostolou <[email protected]> Discussion: https://postgr.es/m/b1843124-fd22-e279-a31f-252dffb6fbf2%40gmx.net --- doc/src/sgml/config.sgml | 37 +++++++++++++++++++ src/backend/storage/file/fd.c | 3 ++ src/backend/storage/smgr/md.c | 21 ++++++++--- src/backend/utils/misc/guc_parameters.dat | 7 ++++ src/backend/utils/misc/guc_tables.c | 9 +++++ src/backend/utils/misc/postgresql.conf.sample | 4 ++ src/include/storage/fd.h | 11 ++++++ 7 files changed, 87 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 405c9689bd0..0b4922b35c4 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2410,6 +2410,43 @@ include_dir 'conf.d' </listitem> </varlistentry> + <varlistentry id="guc-file-extend-method" xreflabel="file_extend_method"> + <term><varname>file_extend_method</varname> (<type>enum</type>) + <indexterm> + <primary><varname>file_extend_method</varname> configuration parameter</primary> + </indexterm> + </term> + <listitem> + <para> + Specifies the method used to extend data files during bulk operations + such as <command>COPY</command>. The first available option is used as + the default, depending on the operating system: + <itemizedlist> + <listitem> + <para> + <literal>posix_fallocate</literal> (Unix) uses the standard POSIX + interface for allocating disk space, but is missing on some systems. + If it is present but the underlying file system doesn't support it, + this option silently falls back to <literal>write_zeros</literal>. + Current versions of BTRFS are known to disable compression when + this option is used. + This is the default on systems that have the function. + </para> + </listitem> + <listitem> + <para> + <literal>write_zeros</literal> extends files by writing out blocks + of zero bytes. This is the default on systems that don't have the + function <function>posix_fallocate</function>. + </para> + </listitem> + </itemizedlist> + The <literal>write_zeros</literal> method is always used when data + files are extended by 8 blocks or fewer. + </para> + </listitem> + </varlistentry> + <varlistentry id="guc-max-notify-queue-pages" xreflabel="max_notify_queue_pages"> <term><varname>max_notify_queue_pages</varname> (<type>integer</type>) <indexterm> diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c index 9670e809b72..a2fd55cc408 100644 --- a/src/backend/storage/file/fd.c +++ b/src/backend/storage/file/fd.c @@ -164,6 +164,9 @@ bool data_sync_retry = false; /* How SyncDataDirectory() should do its job. */ int recovery_init_sync_method = DATA_DIR_SYNC_METHOD_FSYNC; +/* How data files should be bulk-extended with zeros. */ +int file_extend_method = DEFAULT_FILE_EXTEND_METHOD; + /* Which kinds of files should be opened with PG_O_DIRECT. */ int io_direct_flags; diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c index 71bcdeb6601..df0aa20708d 100644 --- a/src/backend/storage/smgr/md.c +++ b/src/backend/storage/smgr/md.c @@ -602,13 +602,24 @@ mdzeroextend(SMgrRelation reln, ForkNumber forknum, * that decision should be made though? For now just use a cutoff of * 8, anything between 4 and 8 worked OK in some local testing. */ - if (numblocks > 8) + if (numblocks > 8 && + file_extend_method != FILE_EXTEND_METHOD_WRITE_ZEROS) { - int ret; + int ret = 0; - ret = FileFallocate(v->mdfd_vfd, - seekpos, (pgoff_t) BLCKSZ * numblocks, - WAIT_EVENT_DATA_FILE_EXTEND); +#ifdef HAVE_POSIX_FALLOCATE + if (file_extend_method == FILE_EXTEND_METHOD_POSIX_FALLOCATE) + { + ret = FileFallocate(v->mdfd_vfd, + seekpos, (pgoff_t) BLCKSZ * numblocks, + WAIT_EVENT_DATA_FILE_EXTEND); + } + else +#endif + { + elog(ERROR, "unsupported file_extend_method: %d", + file_extend_method); + } if (ret != 0) { ereport(ERROR, diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat index 3b9d8349078..220a092ef52 100644 --- a/src/backend/utils/misc/guc_parameters.dat +++ b/src/backend/utils/misc/guc_parameters.dat @@ -1039,6 +1039,13 @@ options => 'file_copy_method_options', }, +{ name => 'file_extend_method', type => 'enum', context => 'PGC_SIGHUP', group => 'RESOURCES_DISK', + short_desc => 'Selects the method used for extending data files.', + variable => 'file_extend_method', + boot_val => 'DEFAULT_FILE_EXTEND_METHOD', + options => 'file_extend_method_options', +}, + { name => 'from_collapse_limit', type => 'int', context => 'PGC_USERSET', group => 'QUERY_TUNING_OTHER', short_desc => 'Sets the FROM-list size beyond which subqueries are not collapsed.', long_desc => 'The planner will merge subqueries into upper queries if the resulting FROM list would have no more than this many items.', diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c index f87b558c2c6..6c65a47a88d 100644 --- a/src/backend/utils/misc/guc_tables.c +++ b/src/backend/utils/misc/guc_tables.c @@ -80,6 +80,7 @@ #include "storage/bufmgr.h" #include "storage/bufpage.h" #include "storage/copydir.h" +#include "storage/fd.h" #include "storage/io_worker.h" #include "storage/large_object.h" #include "storage/pg_shmem.h" @@ -491,6 +492,14 @@ static const struct config_enum_entry file_copy_method_options[] = { {NULL, 0, false} }; +static const struct config_enum_entry file_extend_method_options[] = { +#ifdef HAVE_POSIX_FALLOCATE + {"posix_fallocate", FILE_EXTEND_METHOD_POSIX_FALLOCATE, false}, +#endif + {"write_zeros", FILE_EXTEND_METHOD_WRITE_ZEROS, false}, + {NULL, 0, false} +}; + /* * Options for enum values stored in other modules */ diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index dc9e2255f8a..753a42e8ca5 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -179,6 +179,10 @@ # in kilobytes, or -1 for no limit #file_copy_method = copy # copy, clone (if supported by OS) +#file_extend_method = posix_fallocate # the default is the first option supported + # by the operating system: + # posix_fallocate (most Unix-like systems) + # write_zeros #max_notify_queue_pages = 1048576 # limits the number of SLRU pages allocated # for NOTIFY / LISTEN queue diff --git a/src/include/storage/fd.h b/src/include/storage/fd.h index a8b0c9b3997..f21ac4545a8 100644 --- a/src/include/storage/fd.h +++ b/src/include/storage/fd.h @@ -55,12 +55,23 @@ typedef int File; #define IO_DIRECT_WAL 0x02 #define IO_DIRECT_WAL_INIT 0x04 +enum FileExtendMethod +{ +#ifdef HAVE_POSIX_FALLOCATE + FILE_EXTEND_METHOD_POSIX_FALLOCATE, +#endif + FILE_EXTEND_METHOD_WRITE_ZEROS, +}; + +/* Default to the first available file_extend_method. */ +#define DEFAULT_FILE_EXTEND_METHOD 0 /* GUC parameter */ extern PGDLLIMPORT int max_files_per_process; extern PGDLLIMPORT bool data_sync_retry; extern PGDLLIMPORT int recovery_init_sync_method; extern PGDLLIMPORT int io_direct_flags; +extern PGDLLIMPORT int file_extend_method; /* * This is private to fd.c, but exported for save/restore_backend_variables() -- 2.51.2
From c5b1fd2fdcf41de11d2701602d3e243df9bbb049 Mon Sep 17 00:00:00 2001 From: Thomas Munro <[email protected]> Date: Mon, 15 Dec 2025 16:16:23 +1300 Subject: [PATCH v2 2/3] Add file_extend_method_threshold setting. Previously, write_zeros behavior was used at or below a hard-coded extension size of 8, based on tests with common Linux file systems. Make it user-adjustable, to allow testing on other systems. Discussion: https://postgr.es/m/b1843124-fd22-e279-a31f-252dffb6fbf2%40gmx.net --- doc/src/sgml/config.sgml | 21 ++++++++++++++++++- src/backend/storage/file/fd.c | 3 +++ src/backend/storage/smgr/md.c | 6 ++---- src/backend/utils/misc/guc_parameters.dat | 8 +++++++ src/backend/utils/misc/postgresql.conf.sample | 1 + src/include/storage/fd.h | 8 +++++++ 6 files changed, 42 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 0b4922b35c4..5a298646100 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2442,7 +2442,26 @@ include_dir 'conf.d' </listitem> </itemizedlist> The <literal>write_zeros</literal> method is always used when data - files are extended by 8 blocks or fewer. + files are extended by <literal>file_extend_method_threshold</literal> + or fewer blocks. + </para> + </listitem> + </varlistentry> + + <varlistentry id="guc-file-extend-method-threshold" xreflabel="file_extend_method_threshold"> + <term><varname>file_extend_method_threshold</varname> (<type>integer</type>) + <indexterm> + <primary><varname>file_extend_method_threshold</varname> configuration parameter</primary> + </indexterm> + </term> + <listitem> + <para> + <literal>posix_fallocate</literal> is known to interfere with + delayed allocation heuristics on some file systems, when the extension + size is small. This setting specifies the size up to which + <literal>write_zeros</literal> is used, overriding the + <literal>file_extend_method</literal> setting. The default is 8 + blocks. </para> </listitem> </varlistentry> diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c index a2fd55cc408..7eb537ab15e 100644 --- a/src/backend/storage/file/fd.c +++ b/src/backend/storage/file/fd.c @@ -167,6 +167,9 @@ int recovery_init_sync_method = DATA_DIR_SYNC_METHOD_FSYNC; /* How data files should be bulk-extended with zeros. */ int file_extend_method = DEFAULT_FILE_EXTEND_METHOD; +/* At what size file_extend_method is used instead of write_zeros. */ +int file_extend_method_threshold = DEFAULT_FILE_EXTEND_METHOD_THRESHOLD; + /* Which kinds of files should be opened with PG_O_DIRECT. */ int io_direct_flags; diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c index df0aa20708d..f893687814b 100644 --- a/src/backend/storage/smgr/md.c +++ b/src/backend/storage/smgr/md.c @@ -598,11 +598,9 @@ mdzeroextend(SMgrRelation reln, ForkNumber forknum, * to allocate page cache space for the extended pages. * * However, we don't use FileFallocate() for small extensions, as it - * defeats delayed allocation on some filesystems. Not clear where - * that decision should be made though? For now just use a cutoff of - * 8, anything between 4 and 8 worked OK in some local testing. + * defeats delayed allocation on some filesystems. */ - if (numblocks > 8 && + if (numblocks > file_extend_method_threshold && file_extend_method != FILE_EXTEND_METHOD_WRITE_ZEROS) { int ret = 0; diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat index 220a092ef52..964e107c7a5 100644 --- a/src/backend/utils/misc/guc_parameters.dat +++ b/src/backend/utils/misc/guc_parameters.dat @@ -1046,6 +1046,14 @@ options => 'file_extend_method_options', }, +{ name => 'file_extend_method_threshold', type => 'int', context => 'PGC_SIGHUP', group => 'RESOURCES_DISK', + short_desc => 'Specifies the extension size above which file_extend_method is used.', + variable => 'file_extend_method_threshold', + boot_val => 'DEFAULT_FILE_EXTEND_METHOD_THRESHOLD', + min => '1', + max => 'INT_MAX', +}, + { name => 'from_collapse_limit', type => 'int', context => 'PGC_USERSET', group => 'QUERY_TUNING_OTHER', short_desc => 'Sets the FROM-list size beyond which subqueries are not collapsed.', long_desc => 'The planner will merge subqueries into upper queries if the resulting FROM list would have no more than this many items.', diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index 753a42e8ca5..b745e31a38d 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -179,6 +179,7 @@ # in kilobytes, or -1 for no limit #file_copy_method = copy # copy, clone (if supported by OS) +#file_extend_method_threshold = 8 # size up to which write_zeros is used #file_extend_method = posix_fallocate # the default is the first option supported # by the operating system: # posix_fallocate (most Unix-like systems) diff --git a/src/include/storage/fd.h b/src/include/storage/fd.h index f21ac4545a8..7074c3f118b 100644 --- a/src/include/storage/fd.h +++ b/src/include/storage/fd.h @@ -66,12 +66,20 @@ enum FileExtendMethod /* Default to the first available file_extend_method. */ #define DEFAULT_FILE_EXTEND_METHOD 0 +/* + * Values 4-8 were experimentally determined to avoid interference between + * posix_fallocate() and delayed allocation on common Linux file systems, but + * other systems might vary. + */ +#define DEFAULT_FILE_EXTEND_METHOD_THRESHOLD 8 + /* GUC parameter */ extern PGDLLIMPORT int max_files_per_process; extern PGDLLIMPORT bool data_sync_retry; extern PGDLLIMPORT int recovery_init_sync_method; extern PGDLLIMPORT int io_direct_flags; extern PGDLLIMPORT int file_extend_method; +extern PGDLLIMPORT int file_extend_method_threshold; /* * This is private to fd.c, but exported for save/restore_backend_variables() -- 2.51.2
From cfeffb032d96e96016e5b840b07bcf8c04262860 Mon Sep 17 00:00:00 2001 From: Thomas Munro <[email protected]> Date: Mon, 15 Dec 2025 16:39:56 +1300 Subject: [PATCH v2 3/3] Add file_extend_method=ftruncate,chsize options. Since COW file systems can't reserve space for future writes by any means, provide an alternative that should at least be more efficient. At least it delays kernel buffer allocation and skips copying zeros around, like posix_fallocate. "ftruncate" isn't a concept on Windows, so provide a different surface-level option "chsize". It actually differs in a crucially relevant way on the most common file system NTFS: it reserves disk blocks immediately rather than creating a sparse file. On the other hand, it surely can't do that on ReFS, so it seems inappropriate to pretend that Windows has "posix_fallocate". Exposing the true operation's name makes it the user's problem to figure out what the filesystem does when we call it. Tested-by: Dimitrios Apostolou <[email protected]> Discussion: https://postgr.es/m/b1843124-fd22-e279-a31f-252dffb6fbf2%40gmx.net --- doc/src/sgml/config.sgml | 20 ++++++++++++++ src/backend/storage/smgr/md.c | 26 ++++++++++++------- src/backend/utils/misc/guc_tables.c | 1 + src/backend/utils/misc/postgresql.conf.sample | 2 ++ src/include/storage/fd.h | 25 ++++++++++++++++++ 5 files changed, 65 insertions(+), 9 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 5a298646100..ff8b66f52cf 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2440,6 +2440,26 @@ include_dir 'conf.d' function <function>posix_fallocate</function>. </para> </listitem> + <listitem> + <para> + <literal>ftruncate</literal> (Unix) extends files without + allocating space. Out-of-space errors are deferred until PostgreSQL + writes data out later, potentially preventing checkpoints from + completing, so it is not recommended for tradition "overwrite" + file systems. It is provided as an option for copy-on-write file + systems where <literal>posix_fallocate</literal> and + <literal>write_zeros</literal> can't reserve space eagerly, and + <literal>ftruncate</literal> might be more efficient. + </para> + </listitem> + <listitem> + <para> + <literal>chsize</literal> (Windows) allocates space and reports + out-of-space errors immediately on NTFS (like + <literal>posix_fallocate</literal>), but defers allocation on + ReFS (like <literal>fallocate_ftruncate</literal>). + </para> + </listitem> </itemizedlist> The <literal>write_zeros</literal> method is always used when data files are extended by <literal>file_extend_method_threshold</literal> diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c index f893687814b..b65cd308fd3 100644 --- a/src/backend/storage/smgr/md.c +++ b/src/backend/storage/smgr/md.c @@ -595,7 +595,12 @@ mdzeroextend(SMgrRelation reln, ForkNumber forknum, * If available and useful, use posix_fallocate() (via * FileFallocate()) to extend the relation. That's often more * efficient than using write(), as it commonly won't cause the kernel - * to allocate page cache space for the extended pages. + * to allocate page cache space for the extended pages. COW + * filesystems can't really reserve disk space for future writeback + * (possibly moving the ENOSPC error into the checkpointer), but + * ftruncate() can still still be used to defer the kernel cache + * overheads until then. Note that on Windows, ftruncate() is really + * _chsize_s(), which *does* allocate blocks, at least on NTFS. * * However, we don't use FileFallocate() for small extensions, as it * defeats delayed allocation on some filesystems. @@ -605,25 +610,28 @@ mdzeroextend(SMgrRelation reln, ForkNumber forknum, { int ret = 0; + if (file_extend_method == FILE_EXTEND_METHOD_FTRUNCATE) + ret = FileTruncate(v->mdfd_vfd, + seekpos + (pgoff_t) BLCKSZ * numblocks, + WAIT_EVENT_DATA_FILE_EXTEND); #ifdef HAVE_POSIX_FALLOCATE - if (file_extend_method == FILE_EXTEND_METHOD_POSIX_FALLOCATE) - { + else if (file_extend_method == FILE_EXTEND_METHOD_POSIX_FALLOCATE) ret = FileFallocate(v->mdfd_vfd, seekpos, (pgoff_t) BLCKSZ * numblocks, WAIT_EVENT_DATA_FILE_EXTEND); - } - else #endif - { + else elog(ERROR, "unsupported file_extend_method: %d", file_extend_method); - } + if (ret != 0) { ereport(ERROR, errcode_for_file_access(), - errmsg("could not extend file \"%s\" with FileFallocate(): %m", - FilePathName(v->mdfd_vfd)), + errmsg("could not extend file \"%s\" with %s(): %m", + FilePathName(v->mdfd_vfd), + file_extend_method == FILE_EXTEND_METHOD_FTRUNCATE ? + "FileTruncate" : "FileFallocate"), errhint("Check free disk space.")); } } diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c index 6c65a47a88d..63712c9e465 100644 --- a/src/backend/utils/misc/guc_tables.c +++ b/src/backend/utils/misc/guc_tables.c @@ -497,6 +497,7 @@ static const struct config_enum_entry file_extend_method_options[] = { {"posix_fallocate", FILE_EXTEND_METHOD_POSIX_FALLOCATE, false}, #endif {"write_zeros", FILE_EXTEND_METHOD_WRITE_ZEROS, false}, + {FILE_EXTEND_METHOD_FTRUNCATE_NAME, FILE_EXTEND_METHOD_FTRUNCATE, false}, {NULL, 0, false} }; diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index b745e31a38d..18ed8a6a549 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -184,6 +184,8 @@ # by the operating system: # posix_fallocate (most Unix-like systems) # write_zeros + # ftruncate (Unix) + # chsize (Windows) #max_notify_queue_pages = 1048576 # limits the number of SLRU pages allocated # for NOTIFY / LISTEN queue diff --git a/src/include/storage/fd.h b/src/include/storage/fd.h index 7074c3f118b..bb1729a41d1 100644 --- a/src/include/storage/fd.h +++ b/src/include/storage/fd.h @@ -61,11 +61,36 @@ enum FileExtendMethod FILE_EXTEND_METHOD_POSIX_FALLOCATE, #endif FILE_EXTEND_METHOD_WRITE_ZEROS, + FILE_EXTEND_METHOD_FTRUNCATE, }; /* Default to the first available file_extend_method. */ #define DEFAULT_FILE_EXTEND_METHOD 0 +#ifdef WIN32 + + /* + * Even though file_extend_method=chsize uses the same code path as + * file_extend_method=ftruncate, our ftruncate() macro for Windows expands to + * _chsize_s(), whose filesystem-dependent behavior might not match + * ftruncate() in a relevant way: + * + * 1. NTFS allocates physical blocks so that overwriting them later can't + * fail with ENOSPC. It would be confusing and misleading to label it + * "ftruncate", as it sounds like a recipe for sparse files. + * + * 2. ReFS doesn't, being a COW system, and nor is allocation in the + * function's contract, so it would also be also be misleading to label it + * "posix_fallocate". + * + * We don't know what the file system does, and Unix terminology would only + * obfuscate matters, so we expose the name of the real OS function. + */ +#define FILE_EXTEND_METHOD_FTRUNCATE_NAME "chsize" +#else +#define FILE_EXTEND_METHOD_FTRUNCATE_NAME "ftruncate" +#endif + /* * Values 4-8 were experimentally determined to avoid interference between * posix_fallocate() and delayed allocation on common Linux file systems, but -- 2.51.2
