{"Entry":{"collection":"storage","key":"fork-vm","name":"vm fork","aliases":[],"metadata":{"aliases":[],"category":"Relation forks","content_hash":"81541f39506de6e8f7ec102bb097e7d8e597eeeb7ec9db7657e8a3d807575178","derived_content_hash":"ffbc2dffdc46b225cbf5e3d6e8acfe168c8515b0f70bef62658f1462dea26b7a","imported_at":"2026-09-30T00:40:47.134958+08:00","name":"vm fork","name_zh":"","slug":"fork-vm","summary":"Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 )."}},"Definition":{"Collection":"storage","Key":"fork-vm","SourceDatabase":"center","Version":"18","SourceTable":"storage_structure","SourceKey":"fork-vm","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"comparison_data":{"fork":"vm"},"comparison_hash":"0f7e444c74befed2e9e038b208922f35c10a3caa1ec789947fda5dd19339d4d4","description":["Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 ).","When a table or index exceeds 1 GB, it is divided into gigabyte-sized segments . The first segment's file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL .) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice."],"description_zh":"本节从文件和目录的层次描述存储格式。 传统上，数据库集簇所使用的配置文件和数据文件都存放在集簇的数据目录中，这个目录通常称为 PGDATA （名字来自可用于定义它的环境变量）。 PGDATA 的一个常见位置是 /var/lib/pgsql/data 。同一台机器上可以存在多个由不同服务器实例管理的集簇。 PGDATA 目录包含若干子目录和控制文件，如 表 66.1 所示。除这些必需项之外，集簇配置文件 postgresql.conf 、 pg_hba.conf 和 pg_ident.conf 传统上也存放在 PGDATA 中，不过也可以把它们放在其他地方。 对于集簇中的每个数据库， PGDATA /base 中都有一个子目录，其名称是该数据库在 pg_database 中的 OID。这个子目录是该数据库文件的默认位置；特别是，它的系统目录就存放在这里。","description_zh_html":"\u003cp\u003e存储结构 fork-vm。\u003c/p\u003e\u003ch3\u003e同版本中文手册节选\u003c/h3\u003e\u003cp\u003e\n本节从文件和目录的层次描述存储格式。\n\u003c/p\u003e\u003cp\u003e\n传统上，数据库集簇所使用的配置文件和数据文件都存放在集簇的数据目录中，这个目录通常称为 \u003ccode class=\"varname\"\u003ePGDATA\u003c/code\u003e（名字来自可用于定义它的环境变量）。\u003ccode class=\"varname\"\u003ePGDATA\u003c/code\u003e 的一个常见位置是\n\u003ccode class=\"filename\"\u003e/var/lib/pgsql/data\u003c/code\u003e。同一台机器上可以存在多个由不同服务器实例管理的集簇。\n\u003c/p\u003e\u003cp\u003e\n\u003ccode class=\"varname\"\u003ePGDATA\u003c/code\u003e 目录包含若干子目录和控制文件，如\u003ca class=\"xref\" href=\"/zh/docs/18/storage-file-layout.html#PGDATA-CONTENTS-TABLE\"\u003e表 66.1\u003c/a\u003e 所示。除这些必需项之外，集簇配置文件\n\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e、\u003ccode class=\"filename\"\u003epg_hba.conf\u003c/code\u003e 和\n\u003ccode class=\"filename\"\u003epg_ident.conf\u003c/code\u003e 传统上也存放在 \u003ccode class=\"varname\"\u003ePGDATA\u003c/code\u003e\n中，不过也可以把它们放在其他地方。\n\u003c/p\u003e\u003cp\u003e\n对于集簇中的每个数据库，\u003ccode class=\"varname\"\u003ePGDATA\u003c/code\u003e\u003ccode class=\"filename\"\u003e/base\u003c/code\u003e\n中都有一个子目录，其名称是该数据库在 \u003ccode class=\"structname\"\u003epg_database\u003c/code\u003e\n中的 OID。这个子目录是该数据库文件的默认位置；特别是，它的系统目录就存放在这里。\n\u003c/p\u003e\u003cp\u003e\u003ca href=\"/zh/docs/18/storage-file-layout.html\"\u003e查看完整中文手册与上下文\u003c/a\u003e。\u003c/p\u003e","facts":[{"label":"Fork","value":"vm"}],"facts_zh":[{"label":"关系分叉","value":"vm"}],"manual_html":"","manual_path":"/docs/18/storage-file-layout.html","related":[{"label":"Database file layout","url":"/wiki/storage/storage-file-layout/?v=18"}],"release":{"channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sections":[],"sections_zh":[],"signature":"","sources":[{"label":"PostgreSQL 18 English manual","path":"storage-file-layout.html","sha256":"8cdf46b5af669f41f0a77c2541863d63454ef8fbb44d22a75e576cf1a7efc9c9","url":"/docs/18/storage-file-layout.html"}],"tables":[],"tables_zh":[],"zh_from":{"authored_translation":"source-derived-identity","body_sha256":"5f038f4d6f99a8251c67297a88728f15fc048eb1fe67b2b55a31eb99719d0934","kind":"same-version-chinese-manual-with-source-derived-identity","manual":{"anchor":"","build_id":107,"extraction":"concept-introduction","fragment_sha256":"257fb050d6193b915e73cee0d717b72f3e9e669fd98d6e4cebef2941b6a6378b","locale":"zh-Hans","page_key":"storage-file-layout.html","source_hash":"b919cbcb8aedb49e32e5185e2c7753b075945bb7c0e00c59b81974d853143a0a","source_revision":"unknown:rendered-translation-baseline","translated_from_revision":null,"translation_revision":"git:b1b500221dbe5437cfca004d6b04d3f6e422765d;html-sha256:08e987a66af27b98444a8057c256314eafa13611a3fb9e888214fc436824244b","url":"/zh/docs/18/storage-file-layout.html","version":"18"},"runtime_rerun":false,"source_facts_revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}},"ManualEvidence":{"manual_path":"/docs/18/storage-file-layout.html","release":{"channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sources":[{"label":"PostgreSQL 18 English manual","path":"storage-file-layout.html","sha256":"8cdf46b5af669f41f0a77c2541863d63454ef8fbb44d22a75e576cf1a7efc9c9","url":"/docs/18/storage-file-layout.html"}]},"MeasuredEvidence":{}},"Text":{"Collection":"storage","Key":"fork-vm","SourceDatabase":"center","Version":"18","Locale":"en","Title":"vm fork","Summary":"Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 ).\nWhen a table or index exceeds 1 GB, it is divided into gigabyte-sized segments . The first segment's file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL .) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice.","BodyHTML":"\u003cp\u003eEach table and index is stored in a separate file. For ordinary relations, these files are named after the table or index\u0026#39;s filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 ).\nWhen a table or index exceeds 1 GB, it is divided into gigabyte-sized segments . The first segment\u0026#39;s file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL .) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice.\u003c/p\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"0a6c40cdb30fe4802013952bf67b4ec8a002a36ce3a03e5f854c6efd73313c4f","Payload":{"description":["Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 ).","When a table or index exceeds 1 GB, it is divided into gigabyte-sized segments . The first segment's file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL .) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice."],"manual_html":"","related":[{"label":"Database file layout","url":"/wiki/storage/storage-file-layout/?v=18"}],"sections":[],"tables":[]}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}