PostgreSQL最后的救命稻草 — pg_resetwal - PostgreSQLChina的个人空间 - OSCHINA

pg_resetwal— 重置 PostgreSQL 数据库集群的预写日志和其他控制信息

适用版本：PostgreSQL 12/13/14/15

语法

pg_resetwal [ -f | --force ] [ -n | --dry-run ] [option...] [ -D | --pgdata ]datadir

描述
pg_resetwal 清除预写日志 WAL ，并可选地重置pg_control文件中的一些其他控制信息。当 WAL 文件或 pg_control 控制文件损坏时，导致数据库无法启动时，该操作将作为数据库修复的最后手段使用。

通过 pg_resetwal 修复而启动数据库后，可能会由于部分提交的事务，导致数据库可能存在数据不一致的情况。所以，应该立即转储数据，建议重新初始化新的数据库恢复。恢复后再检查不一致，并根据需要进一步修复。

pg_resetwal 只能由安装数据库用户运行，因为它需要对数据目录进行读/写访问。注意：考虑安全原因， pg_resetwal 不使用环境变量 PGDATA，所以必须在命令行上指定数据目录。

如果 pg_resetwa l 提示无法确定pg_control的有效数据，可以通过指定-f（force）选项强制继续执行。大多数字段可以自动匹配，但下一个OID、下一个事务ID和epoch、下一多事务ID和偏移量以及WAL起始位置字段值可能需要手动指定。可以使用一些选项设置这些字段值。如果无法确定这些字段的正确值，也可使用-f，但必须对恢复的数据库更为严谨的处理：必须立即转储和恢复。在转储之前，不要在数据库中执行任何数据修改操作，因为任何此类操作都可能会使损坏更严重。

命令帮助

  [postgres@lyp ~]$ pg_resetwal --help
    pg_resetwal resets the PostgreSQL write-ahead log.
    Usage:
      pg_resetwal [OPTION]... DATADIR
    Options:
      -c, --commit-timestamp-ids=XID,XID    设置带有提交时间戳的最早和最新事务（零表示没有更改）
     [-D, --pgdata=]DATADIR                  数据目录
      -e, --epoch=XIDEPOCH                   设置下一个事务ID纪元epoch
      -f, --force                            强制更新完成
      -l, --next-wal-file=WALFILE            设置新WAL的最小起始位置
      -m, --multixact-ids=MXID,MXID          设置下一个和最旧的多事务ID
      -n, --dry-run                          没有更新，只显示将要执行的操作
      -o, --next-oid=OID                     设置下一个OID
      -O, --multixact-offset=OFFSET          设置下一个多事务偏移量
      -V, --version                          输出版本信息，然后退出
      -x, --next-transaction-id=XID          设置下一个事务ID
          --wal-segsize=SIZE                 WAL段的大小（MB）
      -?, --help                             
    Report bugs to <pgsql-bugs@lists.postgresql.org>.
    PostgreSQL home page: <https://www.postgresql.org/>
    [postgres@lyp ~]$

选项详解

只有当 pg_resetwal 无法通过读取pg_control 来确定适当的值时，才需要以下选项。对于采用数字参数的值，可以使用前缀0x指定十六进制值。

    -c xid1,xid2
    —commit-timestamp-ids=xid1,xid2

手动设置可以检索提交时间的最旧和最新事务ID。

xid1：可以通过在 $PGDATA/pg_commit_ts 目录中查找数值最小的文件名来确定可以检索提交时间的最旧事务ID的安全值（第一部分）。xid2：相反，可以通过在同一目录中查找数值最大的文件名来确定可以检索提交时间的最新事务ID的安全值。文件名为十六进制。

    -e xid_epoch
    —epoch=xid_epoch

手动设置下一个事务ID的epoch。

事务ID epoch实际上并没有保存在数据库中的任何位置，除非存储在由pg_resetwal设置的字段中，因此就数据库本身而言，任何值都是有效的。您可能需要调整此值，以确保复制系统（如Slony-I和Skytools）正常工作-如果是这样，应该可以从下游复制数据库的状态获得适当的值。

    -l walfile
    —next-wal-file=walfile

通过指定下一个WAL段文件的名称，手动设置WAL起始位置。

可以通过 $PGDATA/pg_wal 目录中查找数值最新的WAL段的文件名，+1。这些名称也是十六进制的，有三个部分。第一部分是“时间线ID”，通常应保持不变。例如，如果 0000000100000009000000B7 是pg_wal中最大的条目，请使用 -l 0000000100000009000000B8 或更高。

注意，当使用非默认WAL段大小时，WAL文件名中的数字与系统函数和系统视图报告的LSN不同。此选项采用WAL文件名，而不是LSN。

格式：-l 0000000100000009000000B8

    -m mxid1,mxid2
    —multixact-ids=mxid1,mxid2

手动设置下一个和最旧的多事务ID。

mxid1：下一个多事务ID的安全值可以通过在 $PGDATA/pg_multixact/offsets 目录中查找数值最大的文件名，+1，然后乘以65536（0x10000）来确定。mxid2：相反，最旧的多事务ID的安全值可以通过 $PGDATA/pg_multixact/offsets 目录中数字最小的文件名，乘以65536来确定。文件名是十六进制的，因此最简单的方法是以十六进制指定选项值并附加四个零。

注意：若当前值为0，那么mxid2亦为0，则mxid2取mxid1的值。

格式：-m 0x10000, 0x100000

    -o oid
    —next-oid=oid

手动设置下一个OID。

没有相对简单的方法来确定下一个超出数据库中最大OID的OID，但幸运的是，正确设置下一个OID并不重要。

    -O mxoff
    —multixact-offset=mxoff

手动设置下一个多事务处理偏移量。

安全值可以通过在 $PGDATA/pg_multixact/members 目录中查找数值最大的文件名，+1，然后乘以52352（0xCC80）来确定。文件名为十六进制。没有像附加零的其他选项那样的简单方法。

若找到最大值0000，+1，乘以 52352 (0xCC80)，这个需要进行计算，没有简单的加0的方法。格式：0xCC80

若找到最大值00C1(193)，+1，乘以 52352 (0xCC80)。最后得值：（193+1）* 52352 = 4918288。16进制为：4B0C10，结果为：0x004B0C10

   —wal-segsize=wal_segment_size

设置新的WAL段大小（MB）。该值必须设置为介于1和1024（兆字节）之间的2的幂。

虽然pg_resetwal会将WAL起始地址设置在最新的现有WAL段文件之外，但某些段大小的更改可能会导致重用以前的WAL文件名。如果WAL文件名重叠会导致归档策略出现问题，建议将-l与此选项一起使用以手动设置WAL起始地址。

    -u xid
    —oldest-transaction-id=xid

手动设置最旧的未冻结交易ID。

可以通过在 $PGDATA/pg_xact 目录中查找数值最小的文件名，然后乘以1048576（0x100000）来确定安全值。请注意，文件名是十六进制的，因此最简单的方法是以十六进制指定选项值并附加五个零。例如，如果0007是pg_xact中最小的条目，-u 0x700000将起作用。

    -x xid
    —next-transaction-id=xid

手动设置下一个事务ID。

安全值可以通过在 $PGDATA/pg_xact 目录中查找数值最大的文件名，+1，然后乘以1048576（0x100000）来确定。请注意，文件名是十六进制的。，因此最简单的方法是以十六进制指定选项值并附加五个零。例如，如果0011是pg_xact中最大的条目，-x 0x1200000将起作用（五个尾随零提供正确的乘数）。

使用案例
pg_resetwal 用于丢失一些文件导致数据库无法启动进行修复。需要再次强调 ，pg_resetwal 并不是日常使用的工具，是数据库最后的修复手段。常规性恢复请使用常规手段进行。

使用 pg_resetwal 修复的数据库，一般会正常启动，但是可能会因为参数的不准确而导致数据库存在其他异常问题。

如果因为丢失WAL文件导致数据库不一致，或者控制文件丢失，那么我们只需要通过这个工具生成一个最新的文件就可以强制打开数据库了。

重置WAL

创建测试数据

    [postgres@lyp pg_wal]$ psql
    psql (14.1)
    Type "help" for help.
    postgres=# create table lxs1(id int);
    CREATE TABLE
    postgres=# insert into lxs1 values(1);
    INSERT 0 1
    postgres=# insert into lxs1 values(2);
    INSERT 0 1
    postgres=# checkpoint;
    CHECKPOINT
    postgres=# insert into lxs1 values(3);
    INSERT 0 1
    postgres=#

模拟数据库异常

    [postgres@lyp pg_wal]$ ps -ef |grep postgres
    root      19555  13684  0 16:49 pts/1    00:00:00 su - postgres
    postgres  19556  19555  0 16:49 pts/1    00:00:00 -bash
    postgres  19767  19556  0 16:52 pts/1    00:00:00 psql
    root      19790  18013  0 16:53 pts/2    00:00:00 su - postgres
    postgres  19791  19790  0 16:53 pts/2    00:00:00 -bash
    postgres  19865      1  0 16:54 ?        00:00:00 /opt/pgsql14.1/bin/postgres
    postgres  19866  19865  0 16:54 ?        00:00:00 postgres: logger
    postgres  19868  19865  0 16:54 ?        00:00:00 postgres: checkpointer
    postgres  19869  19865  0 16:54 ?        00:00:00 postgres: background writer
    postgres  19870  19865  0 16:54 ?        00:00:00 postgres: walwriter
    postgres  19871  19865  0 16:54 ?        00:00:00 postgres: autovacuum launcher
    postgres  19872  19865  0 16:54 ?        00:00:00 postgres: archiver failed on 000000010000000000000012
    postgres  19873  19865  0 16:54 ?        00:00:00 postgres: stats collector
    postgres  19874  19865  0 16:54 ?        00:00:00 postgres: logical replication launcher
    postgres  19883  19865  0 16:55 ?        00:00:00 postgres: postgres postgres [local] idle
    postgres  19899  19791  0 16:55 pts/2    00:00:00 ps -ef
    postgres  19900  19791  0 16:55 pts/2    00:00:00 grep --color=auto postgres
    [postgres@lyp pg_wal]$ kill -9 19865
    [postgres@lyp pg_wal]$ ps -ef |grep postgres
    root      19555  13684  0 16:49 pts/1    00:00:00 su - postgres
    postgres  19556  19555  0 16:49 pts/1    00:00:00 -bash
    postgres  19767  19556  0 16:52 pts/1    00:00:00 psql
    root      19790  18013  0 16:53 pts/2    00:00:00 su - postgres
    postgres  19791  19790  0 16:53 pts/2    00:00:00 -bash
    postgres  19901  19791  0 16:55 pts/2    00:00:00 ps -ef
    postgres  19902  19791  0 16:55 pts/2    00:00:00 grep --color=auto postgres
    [postgres@lyp pg_wal]$

删除WAL文件

    [postgres@lyp ~]$ cd $PGDATA/pg_wal
    [postgres@lyp pg_wal]$ ls -lrt
    total 196620
    -rw-------. 1 postgres postgres 16777216 Feb 21  2022 000000010000000000000007
    -rw-------. 1 postgres postgres 16777216 Feb 21  2022 000000010000000000000008
    -rw-------. 1 postgres postgres      345 Feb 21  2022 000000010000000000000008.00000028.backup
    -rw-------. 1 postgres postgres 16777216 Feb 22  2022 000000010000000000000009
    -rw-------. 1 postgres postgres 16777216 Feb 22  2022 00000001000000000000000A
    -rw-------. 1 postgres postgres      318 Feb 22  2022 00000001000000000000000A.00000028.backup
    -rw-------. 1 postgres postgres 16777216 Feb 24  2022 00000001000000000000000B
    -rw-------. 1 postgres postgres 16777216 Feb 24  2022 00000001000000000000000C
    -rw-------. 1 postgres postgres 16777216 Feb 25  2022 00000001000000000000000D
    -rw-------. 1 postgres postgres 16777216 May 10  2022 00000001000000000000000E
    -rw-------. 1 postgres postgres 16777216 Nov 19 23:13 00000001000000000000000F
    -rw-------. 1 postgres postgres 16777216 Nov 26 18:21 000000010000000000000010
    -rw-------. 1 postgres postgres 16777216 Mar 13 16:52 000000010000000000000011
    -rw-------. 1 postgres postgres 16777216 Mar 13 16:52 000000010000000000000012
    drwx------. 2 postgres postgres     4096 Mar 13 16:52 archive_status
    -rw-------. 1 postgres postgres 16777216 Mar 13 16:52 000000010000000000000013
    [postgres@lyp pg_wal]$
    [postgres@lyp pg_wal]$ rm -rf 0000000100000000000000*
    [postgres@lyp pg_wal]$
    [postgres@lyp pg_wal]$ ls -lrt
    total 4
    drwx------. 2 postgres postgres 4096 Mar 13 16:52 archive_status
    [postgres@lyp pg_wal]$

尝试启动数据库

    [postgres@lyp pg_wal]$ pg_ctl start
    pg_ctl: another server might be running; trying to start server anyway
    waiting for server to start....2023-03-13 16:56:07.956 CST [19916] LOG:  redirecting log output to logging collector process
    2023-03-13 16:56:07.956 CST [19916] HINT:  Future log output will appear in directory "log".
     stopped waiting
    pg_ctl: could not start server
    Examine the log output.
    [postgres@lyp pg_wal]$

重置WAL

    [postgres@lyp pg_wal]$ pg_resetwal $PGDATA
    The database server was not shut down cleanly.
    Resetting the write-ahead log might cause data to be lost.
    If you want to proceed anyway, use -f to force reset.
    [postgres@lyp pg_wal]$ pg_resetwal -f $PGDATA
    Write-ahead log reset
    [postgres@lyp pg_wal]$ ls -lrt
    total 16384
    drwx------. 2 postgres postgres        6 Mar 13 17:03 archive_status
    -rw-------. 1 postgres postgres 16777216 Mar 13 17:03 000000010000000000000014
    [postgres@lyp pg_wal]$

启动数据库

    [postgres@lyp pg_wal]$ pg_ctl start
    waiting for server to start....2023-03-13 17:04:10.205 CST [20173] LOG:  redirecting log output to logging collector process
    2023-03-13 17:04:10.205 CST [20173] HINT:  Future log output will appear in directory "log".
     done
    server started
    [postgres@lyp pg_wal]$ psql
    psql (14.1)
    Type "help" for help.
    postgres=# select * from lxs1;
     id
    ----
      1
      2
    (2 rows)
    postgres=#

可以看到测试数据中 checkpoint 检查点后的数据，由于WAL重置而丢失。

重建控制文件

创建测试数据

    [postgres@lyp pg_wal]$ psql
    psql (14.1)
    Type "help" for help.
    postgres=# drop table lxs1;
    DROP TABLE
    postgres=# create table lxs1(id int);
    CREATE TABLE
    postgres=# insert into lxs1 values(1);
    INSERT 0 1
    postgres=# insert into lxs1 values(2);
    INSERT 0 1
    postgres=# checkpoint;
    CHECKPOINT
    postgres=# insert into lxs1 values(3);
    INSERT 0 1
    postgres=#

模拟数据库异常

    [postgres@lyp pg_wal]$ ps -ef |grep postgres
    root      19555  13684  0 16:49 pts/1    00:00:00 su - postgres
    postgres  19556  19555  0 16:49 pts/1    00:00:00 -bash
    postgres  19767  19556  0 16:52 pts/1    00:00:00 psql
    root      19790  18013  0 16:53 pts/2    00:00:00 su - postgres
    postgres  19791  19790  0 16:53 pts/2    00:00:00 -bash
    root      19965  19924  0 16:56 pts/0    00:00:00 su - postgres
    postgres  19966  19965  0 16:56 pts/0    00:00:00 -bash
    postgres  20013  19966  0 16:56 pts/0    00:00:00 tail -100f postgresql-2023-03-13_072.log
    postgres  20272      1  0 17:08 ?        00:00:00 /opt/pgsql14.1/bin/postgres
    postgres  20273  20272  0 17:08 ?        00:00:00 postgres: logger
    postgres  20275  20272  0 17:08 ?        00:00:00 postgres: checkpointer
    postgres  20276  20272  0 17:08 ?        00:00:00 postgres: background writer
    postgres  20277  20272  0 17:08 ?        00:00:00 postgres: walwriter
    postgres  20278  20272  0 17:08 ?        00:00:00 postgres: autovacuum launcher
    postgres  20279  20272  0 17:08 ?        00:00:00 postgres: archiver failed on 000000010000000000000015
    postgres  20280  20272  0 17:08 ?        00:00:00 postgres: stats collector
    postgres  20281  20272  0 17:08 ?        00:00:00 postgres: logical replication launcher
    postgres  20288  20272  0 17:08 ?        00:00:00 postgres: postgres postgres [local] idle
    postgres  20359  19791  0 17:10 pts/2    00:00:00 ps -ef
    postgres  20360  19791  0 17:10 pts/2    00:00:00 grep --color=auto postgres
    [postgres@lyp pg_wal]$ kill -9 20272
    [postgres@lyp pg_wal]$ ps -ef |grep postgres
    root      19555  13684  0 16:49 pts/1    00:00:00 su - postgres
    postgres  19556  19555  0 16:49 pts/1    00:00:00 -bash
    postgres  19767  19556  0 16:52 pts/1    00:00:00 psql
    root      19790  18013  0 16:53 pts/2    00:00:00 su - postgres
    postgres  19791  19790  0 16:53 pts/2    00:00:00 -bash
    root      19965  19924  0 16:56 pts/0    00:00:00 su - postgres
    postgres  19966  19965  0 16:56 pts/0    00:00:00 -bash
    postgres  20013  19966  0 16:56 pts/0    00:00:00 tail -100f postgresql-2023-03-13_072.log
    postgres  20361  19791  0 17:11 pts/2    00:00:00 ps -ef
    postgres  20362  19791  0 17:11 pts/2    00:00:00 grep --color=auto postgres
    [postgres@lyp pg_wal]$

破坏控制文件

    [postgres@lyp pg_wal]$ cd $PGDATA/global
    [postgres@lyp global]$ ls -rlt pg_control
    -rw-------. 1 postgres postgres 8192 Mar 13 17:08 pg_control
    [postgres@lyp global]$ echo "" >pg_control
    [postgres@lyp global]$ ls -rlt pg_control
    -rw-------. 1 postgres postgres 1 Mar 13 17:12 pg_control
    [postgres@lyp global]$

尝试启动数据库

    [postgres@lyp global]$ pg_ctl start
    pg_ctl: another server might be running; trying to start server anyway
    waiting for server to start....2023-03-13 17:13:06.788 CST [20419] PANIC:  could not read file "global/pg_control": read 1 of 296
     stopped waiting
    pg_ctl: could not start server
    Examine the log output.
    [postgres@lyp global]$

重建控制文件

pg_resetwal 重建控制文件，需要参数如下：

    -l walfile
    —next-wal-file=walfile

通过指定下一个WAL段文件的名称，手动设置WAL起始位置。

可以通过 $PGDATA/pg_wal 目录中查找数值最新的WAL段的文件名，+1。

        [postgres@lyp global]$ cd $PGDATA/pg_wal
        [postgres@lyp pg_wal]$ ls -lrt
        total 32768
        -rw-------. 1 postgres postgres 16777216 Mar 13 17:08 000000010000000000000015
        drwx------. 2 postgres postgres       44 Mar 13 17:08 archive_status
        -rw-------. 1 postgres postgres 16777216 Mar 13 17:09 000000010000000000000016
        [postgres@lyp pg_wal]$

当前 000000010000000000000016 是pg_wal中最大的条目，则使用 -l 000000010000000000000017

    -m mxid1,mxid2
    —multixact-ids=mxid1,mxid2

        postgres@lyp offsets]$ ls -lrt
        total 8
        -rw-------. 1 postgres postgres 8192 Mar 13 17:08 0000
        [postgres@lyp offsets]$

当前值为0000，则mxid1为：0x10000，mxid2取mxid1的值，则使用-m 0x10000,0x10000

    -O mxoff
    —multixact-offset=mxoff

手动设置下一个多事务处理偏移量。

安全值可以通过在 $PGDATA/pg_multixact/members 目录中查找数值最大的文件名，+1，然后乘以52352（0xCC80）来确定。文件名为十六进制。没有像附加零的其他选项那样的简单方法。

  [postgres@lyp members]$ ls -rlt
  total 8
  -rw-------. 1 postgres postgres 8192 Feb 21  2022 0000
  [postgres@lyp members]$

当前值为0000，则使用 -O 0xCC80

    -x xid
    —next-transaction-id=xid

手动设置下一个事务ID。

安全值可以通过在$PGDATA/pg_xact目录中查找数值最大的文件名，+1，然后乘以1048576（0x100000）来确定。请注意，文件名是十六进制的。，因此最简单的方法是以十六进制指定选项值并附加五个零。

 [postgres@lyp members]$ cd $PGDATA/pg_xact
 [postgres@lyp pg_xact]$ ls -rlt
 total 8
 -rw-------. 1 postgres postgres 8192 Mar 13 17:08 0000
 [postgres@lyp pg_xact]$

当前值为0000，则使用- x 0x100000

重建控制文件

        [postgres@lyp global]$ pg_resetwal -l 000000010000000000000017 -m 0x10000,0x10000 -O 0xCC80 -x 0x100000 $PGDATA
        pg_resetwal: error: lock file "postmaster.pid" exists
        pg_resetwal: Is a server running?  If not, delete the lock file and try again.
        [postgres@lyp global]$

由于是数据异常关闭，所以存在锁文件，删除后重新执行。

        [postgres@lyp global]$ ls -rlt $PGDATA/postmaster.pid
        -rw-------. 1 postgres postgres 39 Mar 13 17:13 /opt/pgdata14.1/postmaster.pid
        [postgres@lyp global]$ rm -rf  $PGDATA/postmaster.pid
        [postgres@lyp global]$ pg_resetwal -l 000000010000000000000017 -m 0x10000,0x10000 -O 0xCC80 -x 0x100000 $PGDATA
        pg_resetwal: warning: pg_control exists but is broken or wrong version; ignoring it
        Guessed pg_control values:
        pg_control version number:            1300
        Catalog version number:               202107181
        Database system identifier:           7209963927373898017
        Latest checkpoint's TimeLineID:       1
        Latest checkpoint's full_page_writes: off
        Latest checkpoint's NextXID:          0:3
        Latest checkpoint's NextOID:          12000
        Latest checkpoint's NextMultiXactId:  1
        Latest checkpoint's NextMultiOffset:  0
        Latest checkpoint's oldestXID:        3
        Latest checkpoint's oldestXID's DB:   0
        Latest checkpoint's oldestActiveXID:  0
        Latest checkpoint's oldestMultiXid:   1
        Latest checkpoint's oldestMulti's DB: 0
        Latest checkpoint's oldestCommitTsXid:0
        Latest checkpoint's newestCommitTsXid:0
        Maximum data alignment:               8
        Database block size:                  8192
        Blocks per segment of large relation: 131072
        WAL block size:                       8192
        Bytes per WAL segment:                16777216
        Maximum length of identifiers:        64
        Maximum columns in an index:          32
        Maximum size of a TOAST chunk:        1996
        Size of a large-object chunk:         2048
        Date/time type storage:               64-bit integers
        Float8 argument passing:              by value
        Data page checksum version:           0
        Values to be changed:
        First log segment after reset:        000000010000000000000017
        NextMultiXactId:                      65536
        OldestMultiXid:                       65536
        OldestMulti's DB:                     0
        NextMultiOffset:                      52352
        NextXID:                              1048576
        OldestXID:                            3
        OldestXID's DB:                       0
        If these values seem acceptable, use -f to force reset.
        [postgres@lyp global]$
        [postgres@lyp global]$ pg_resetwal -l 000000010000000000000017 -m 0x10000,0x10000 -O 0xCC80 -x 0x100000 $PGDATA -f
        pg_resetwal: warning: pg_control exists but is broken or wrong version; ignoring it
        Write-ahead log reset
        [postgres@lyp global]$
        [postgres@lyp global]$ ls -rlt pg_control
        -rw-------. 1 postgres postgres 8192 Mar 13 17:43 pg_control
        [postgres@lyp global]$

启动数据库

    [postgres@lyp global]$ pg_ctl start
    waiting for server to start....2023-03-13 17:44:00.209 CST [20785] LOG:  redirecting log output to logging collector process
    2023-03-13 17:44:00.209 CST [20785] HINT:  Future log output will appear in directory "log".
     done
    server started
    [postgres@lyp global]$ psql
    psql (14.1)
    Type "help" for help.
    postgres=# select * from lxs1;
     id
    ----
      1
      2
    (2 rows)
    postgres=#

可以看到测试数据中 checkpoint 检查点后的数据，由于控制文件重置而丢失。

注意

1、注意据库正在运行时，不得使用此命令。
2、如果 pg_resetwal 在数据目录中找到服务器锁定文件，将启动失败。
3、如果数据库已崩溃，那么可能会留下一个锁文件（postmaster.pid）；在这种情况下，可以删除锁定文件以保证 postmaster.pid 的正常运行。但在此操作之前，需要再次确保没有数据库进程在运行。
4、pg_resetwal 仅适用于相同主版本的数据库服务器。

点击此处阅读原文

↓↓↓

本文分享自微信公众号 - 开源软件联盟PostgreSQL分会（kaiyuanlianmeng）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

yh2216 2023-12-05 10:07

许久未见如此厚颜无耻的文章了

魔力猫 2023-12-07 19:35

当初的合同呢？相关文档，哪怕是翔，合同规定了也要有。如果没有，可以拒绝验收，不付钱的。而且后续运维，没继续买？

独一无二的柠檬 2023-12-07 20:33

哈哈哈哈，笑死我了

Ayone1 2023-12-07 18:12

还是用java生态吧！

cczywyc 2023-12-04 11:14

不要混淆概念，大家从来都不是反对收费，它是违反了 MIT 开源协议，明白吗？

ZCShou 2023-12-04 09:28

人家@AdminBj也没抨击你，只是客观评论，你这个就给人扣了个社交平台宣泄引众议的帽子！无论买不买 VIP，人家都有权在任何平台发表自己的言论，你的 VIP 还包括限制用户发言的条款么？以后会不会加任何时候必须对你唯命是从的条款啊

yejun365 2023-12-01 22:07

对错都不谈了，还说个毛线啊。首先，文档以前包含在源码里，也是开源的，现在删了。用户有权部署之前开源版文档，现在他说不允许你部署，这是违反开源协议的。兴趣是不能成为饿肚子的理由，但也不是把以前承诺当屁放了的理由！！！！重发一位网友的反对理由！

osc_17596398 2023-12-07 18:00

我用firefox有15+年了，xul扩展废除后，又找并学了uc.js续命，配上uc.js真的比chrome系好用。uc.js都放在github上了

卡塌西瓦 2023-12-07 21:27

我也想搞内核

dplm30 2023-12-07 19:42

debian系统应该出来加油助威

云舒丶Bob 2023-12-07 21:32

AI 没有激活码

cxc236 2023-12-08 00:24

还以为是道歉的帖子，却还是在文过饰非。

monkey_cici 2023-12-04 10:01

各大厂，干活的老程序员都被炒鱿鱼了，新人便宜又勤奋，但是上来接手就懵逼，到处都是坑，维护起来处处是坑.....这些就是开猿节流,降本增笑的影响了....

陈钇蒙 2023-12-04 10:51

都看到马斯克裁了70%的推特员工, 推特也就宕机几次罢了, 大厂们觉得这样做划算, 所以纷纷效仿, 没准他们觉得用几次宕机换一大堆裁员划得来

从今以后 2023-12-05 09:24

这根本不是钱不钱的问题，就这就是赤裸裸的诈骗！现骗你过来说没有套路。等你用上了，再改协议。他今日可以文档收费，他日也可以其他地方再套路收费。

无尽的拉格朗日 2023-12-07 18:31

真牛叉，真毒啊，真能毒

mvpint 2023-12-05 09:38

最后写出优雅代码，让后人看懂，然后35岁后滚蛋，这就是现实，这就是资本主义😹

思北谢Special 2023-12-02 10:36

开始用MIT完全不限制商用这个宽松协议，忽悠大家用上，很多程序员冒着被质疑，去说服公司用，如果你是GPL有多少敢用？而一旦大家用上了，轻易更换代价很大，这时候封闭文档收费，完全撕毁MIT协议，这么玩，其实是损害了所有国产开源软件的信誉度，所有国产开源软件的同仁都应该出来抵制，在社会里，大家要遵守一些底线，当有人突破了底线开始赚钱的时候，其实是损害了同行的信誉度，而那些守规矩的人将更加难以生存，当有人再想以MIT协议推出开源软件的时候，大家就会说：国产的软件用MIT协议你也敢信？

顾真牛 2023-12-03 14:00

之前在知乎，因为有个人发表了一点自己对框架的看法，就跑去人家github下面威胁人家的好像就是这位吧？所以，这有啥好奇怪的？？

杂毛兔 2023-12-07 18:17

星爷都那么努力，汗颜了

monkey_cici 2023-12-07 20:02

自己训练出来的.pt或者转换后的onnx模型，都要遵守AGPL协议，整个项目开源... AGPL = GPL + 服务器也需要开源。 GPL = 如果你的软件二进制分发，需要开源. AGPL = 即使是用来提供 web 服务，云服务的代码也必须开源

zhuzhua 2023-12-04 14:57

对的，坐船到河中间，开始收费了，和TM劫道的有啥区别？学水浒传呢？

IdleMan 2023-12-07 20:58

Mysql：MySQL is one of the most popular relational database systems！ Sqlite:?

UOSCN 2023-12-03 20:34

对话百小僧，首先你这肯定是不犯法，但是违背行业规则，破坏行业规则；破坏的是技术圈开源精神，违背行业规则。如果行业人员多数认为不合理。那就用脚投票，过度完这波就换架构吧。毕竟一个人的诚信还是很重要的。本来互联网技术圈基于信任使用了你的框架，但是现在中途收费，这算什么，在绝大多数人认知里都认为是割韭菜吧；记得作者号称千万star吗？看看最近购买文档、VIP数量，实际转化率不足1%，这些转化率是否包含了采用框架去开发后不得不购买的原因，所以大家都是用脚投票，但是有些人不得不屈服；

疯

疯狂的狮子Li 2023-12-03 23:58

挨个大厂走一圈呗这节奏