读取 PostgreSQL 数据目录文件
Read PostgreSQL data directory files
如何查看和读取 PostgreSQL "data\base" 目录中的文件。
我尝试使用 "pg_ctl" 将此目录作为数据库导入到我的服务器，但失败了。我尝试制作一个 tar 存档并使用 pgadmin 恢复它，但它 return toc 标题错误。
我知道 "data/base" 中的每个文件夹都是一个数据库 OID，每个文件都是 table 和相关数据。
这些文件像这样的二进制文件或 dat 文件：(16384/1174)
€ëÌ 0 ðð b10ëÌ Ô ð àŸ ÀŸ °Ÿ Ÿ €Ÿ pŸ Ÿ PŸ @Ÿ 0Ÿ Ÿ Ÿ Ÿ ðž àž Ðž Àž °ž ž ž €ž pžž Pž @ž 0ž ž ž ž ð à Ð À ° € p P @ 0 ðœ àœ Ðœ Àœ °œ œ œ €œ pœo Pœ @o 0o o oo oo ð› à› Ð› À› °› › › €› p› `› P› @› 0› › › › ðš àš Ðš Àš °š š
有什么方法可以查看和阅读吗？？
我想检索其中的 tables 和数据。
我搜索了很多但没有找到任何真正的解决方案。
请帮忙。多谢。
都没有pg_ctl。 pgAdmin 和任何 SQL 客户端都不能自己处理数据库文件。如果你想阅读文件，你应该研究页面结构（下面的link）以及如何使用这些知识。所以回答有没有办法查看和阅读？？ 是的，基本上你在问题中引用了内容。但是你不能用它来构造 table 或索引数据。除非你支持 postgres。或者尝试破解它，让它认为您的 16384/1174 文件是现有关系 - 我相信两者都超出了 SO 范围。
下面是关于结构的一些参考，您可以尝试阅读
https://www.postgresql.org/docs/current/static/storage-page-layout.html
Every table and index is stored as an array of pages of a fixed size
还有：
The first 24 bytes of each page consists of a page header
(PageHeaderData). Its format is detailed in Table 66.3. The first
field tracks the most recent WAL entry related to this page. The
second field contains the page checksum if data checksums are enabled.
Next is a 2-byte field containing flag bits. This is followed by three
2-byte integer fields (pd_lower, pd_upper, and pd_special). These
contain byte offsets from the page start to the start of unallocated
space, to the end of unallocated space, and to the start of the
special space. The next 2 bytes of the page header,
pd_pagesize_version, store both the page size and a version indicator.
Beginning with PostgreSQL 8.3 the version number is 4; PostgreSQL 8.1
and 8.2 used version number 3; PostgreSQL 8.0 used version number 2;
PostgreSQL 7.3 and 7.4 used version number 1; prior releases used
version number 0. (The basic page layout and header format has not
changed in most of these versions, but the layout of heap row headers
has.) The page size is basically only present as a cross-check; there
is no support for having more than one page size in an installation.
The last field is a hint that shows whether pruning the page is likely
to be profitable: it tracks the oldest un-pruned XMAX on the page.
如何查看和读取 PostgreSQL "data\base" 目录中的文件。 我尝试使用 "pg_ctl" 将此目录作为数据库导入到我的服务器，但失败了。我尝试制作一个 tar 存档并使用 pgadmin 恢复它，但它 return toc 标题错误。 我知道 "data/base" 中的每个文件夹都是一个数据库 OID，每个文件都是 table 和相关数据。 这些文件像这样的二进制文件或 dat 文件：(16384/1174)
€ëÌ 0 ðð b10ëÌ Ô ð àŸ ÀŸ °Ÿ Ÿ €Ÿ pŸ Ÿ PŸ @Ÿ 0Ÿ Ÿ Ÿ Ÿ ðž àž Ðž Àž °ž ž ž €ž pžž Pž @ž 0ž ž ž ž ð à Ð À ° € p P @ 0 ðœ àœ Ðœ Àœ °œ œ œ €œ pœo Pœ @o 0o o oo oo ð› à› Ð› À› °› › › €› p› `› P› @› 0› › › › ðš àš Ðš Àš °š š
有什么方法可以查看和阅读吗？？ 我想检索其中的 tables 和数据。 我搜索了很多但没有找到任何真正的解决方案。 请帮忙。多谢。
都没有pg_ctl。 pgAdmin 和任何 SQL 客户端都不能自己处理数据库文件。如果你想阅读文件，你应该研究页面结构（下面的link）以及如何使用这些知识。所以回答有没有办法查看和阅读？？ 是的，基本上你在问题中引用了内容。但是你不能用它来构造 table 或索引数据。除非你支持 postgres。或者尝试破解它，让它认为您的 16384/1174 文件是现有关系 - 我相信两者都超出了 SO 范围。
下面是关于结构的一些参考，您可以尝试阅读
https://www.postgresql.org/docs/current/static/storage-page-layout.html
Every table and index is stored as an array of pages of a fixed size
还有：
The first 24 bytes of each page consists of a page header (PageHeaderData). Its format is detailed in Table 66.3. The first field tracks the most recent WAL entry related to this page. The second field contains the page checksum if data checksums are enabled. Next is a 2-byte field containing flag bits. This is followed by three 2-byte integer fields (pd_lower, pd_upper, and pd_special). These contain byte offsets from the page start to the start of unallocated space, to the end of unallocated space, and to the start of the special space. The next 2 bytes of the page header, pd_pagesize_version, store both the page size and a version indicator. Beginning with PostgreSQL 8.3 the version number is 4; PostgreSQL 8.1 and 8.2 used version number 3; PostgreSQL 8.0 used version number 2; PostgreSQL 7.3 and 7.4 used version number 1; prior releases used version number 0. (The basic page layout and header format has not changed in most of these versions, but the layout of heap row headers has.) The page size is basically only present as a cross-check; there is no support for having more than one page size in an installation. The last field is a hint that shows whether pruning the page is likely to be profitable: it tracks the oldest un-pruned XMAX on the page.