The database cluster was initialized with RELSEG_SIZE 1048576, but the server was compiled with RELSEG_SIZE 8388608

　　由于一次误操作，将线上机器的数据库程序目录删除，虽然不影响程序的正常使用，数据也未丢失，但后面如果出现服务器宕机或数据库宕机，数据库将无法启动，而且数据库对应的编译参数也已无法查看，所以征得开发同意后，关闭数据库，重新编译数据库程序，尝试可能正确的参数。其中最重要的是关于数据大小的几个：

  --with-blocksize=BLOCKSIZE
                          set table block size in kB [8]
  --with-segsize=SEGSIZE  set table segment size in GB [1]
  --with-wal-blocksize=BLOCKSIZE
                          set WAL block size in kB [8]
  --with-wal-segsize=SEGSIZE
                          set WAL segment size in MB [16]

如有一个不一致，数据库程序将无法启动数据库。

　　刚开始，是根据线上常见几个参数做的尝试，有几次报错，其中block size和wal blocks大小不一致的可以很简单识别，但报的错误中有报出RELSEG_SIZE不一致的，百度、google都没查到这个对应的哪个参数，好在数据都在，后面通过查看数据表的大小来确定了--with-wal-segsize大小为64，--with-segsize大小为8。

　　事后，查看相关资料，发现下面几个对应关系：

XLOG_SEG_SIZE  ----  --with-wal-segsize
RELSEG_SIZE    ----  --with-segsize
XLOG_BLCKSZ    ----  --with-wal-blocksize
BLCKSZ         ----  --with-blocksize

 

　　感觉pg的资料还是较少，遇到一些报错的时候，只能看代码中有无说明：

　　下面是在src\backend\storage\smgr\md.c中查到的说明：

The magnetic disk storage manager keeps track of open file
descriptors in its own descriptor pool. This is done to make it
easier to support relations that are larger than the operating
system's file size limit (often 2GBytes). In order to do that,
we break relations up into "segment" files that are each shorter than
the OS file size limit. The segment size is set by the RELSEG_SIZE
configuration constant in pg_config.h.

 　　在src\include\access\xlog_internal.h查到：

  The XLOG is split into WAL segments (physical files) of the size indicated
  by XLOG_SEG_SIZE.

 

　　编译数据库后的参数可以通过pg_controldata和pg_config查看。但由于没有了应用程序，所以也就没有了这个渠道。pg_controldata是读取的pg_control file的信息，但pg_control是二进制文件，无法查看，使用strings查看显示为空，说明其中没有可以直接打印的信息。之前了解过丢失pg_control文件如何恢复，至于从pg_control 文件恢复配置信息，后面再研究一下。

 

参考：

src\backend\storage\smgr\md.c

src\include\access\xlog_internal.h