PostgreSQL最后的救命稻草

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

命令帮助

  [postgres@lyp ~]$ pg_resetwal --helppg_resetwal resets the PostgreSQL write-ahead log.Usage:pg_resetwal [OPTION]... DATADIROptions:-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]$ psqlpsql (14.1)Type "help" for help.postgres=# create table lxs1(id int);CREATE TABLEpostgres=# insert into lxs1 values(1);INSERT 0 1postgres=# insert into lxs1 values(2);INSERT 0 1postgres=# checkpoint;CHECKPOINTpostgres=# insert into lxs1 values(3);INSERT 0 1postgres=#

模拟数据库异常

    [postgres@lyp pg_wal]$ ps -ef |grep postgresroot      19555  13684  0 16:49 pts/1    00:00:00 su - postgrespostgres  19556  19555  0 16:49 pts/1    00:00:00 -bashpostgres  19767  19556  0 16:52 pts/1    00:00:00 psqlroot      19790  18013  0 16:53 pts/2    00:00:00 su - postgrespostgres  19791  19790  0 16:53 pts/2    00:00:00 -bashpostgres  19865      1  0 16:54 ?        00:00:00 /opt/pgsql14.1/bin/postgrespostgres  19866  19865  0 16:54 ?        00:00:00 postgres: loggerpostgres  19868  19865  0 16:54 ?        00:00:00 postgres: checkpointerpostgres  19869  19865  0 16:54 ?        00:00:00 postgres: background writerpostgres  19870  19865  0 16:54 ?        00:00:00 postgres: walwriterpostgres  19871  19865  0 16:54 ?        00:00:00 postgres: autovacuum launcherpostgres  19872  19865  0 16:54 ?        00:00:00 postgres: archiver failed on 000000010000000000000012postgres  19873  19865  0 16:54 ?        00:00:00 postgres: stats collectorpostgres  19874  19865  0 16:54 ?        00:00:00 postgres: logical replication launcherpostgres  19883  19865  0 16:55 ?        00:00:00 postgres: postgres postgres [local] idlepostgres  19899  19791  0 16:55 pts/2    00:00:00 ps -efpostgres  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 postgresroot      19555  13684  0 16:49 pts/1    00:00:00 su - postgrespostgres  19556  19555  0 16:49 pts/1    00:00:00 -bashpostgres  19767  19556  0 16:52 pts/1    00:00:00 psqlroot      19790  18013  0 16:53 pts/2    00:00:00 su - postgrespostgres  19791  19790  0 16:53 pts/2    00:00:00 -bashpostgres  19901  19791  0 16:55 pts/2    00:00:00 ps -efpostgres  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 -lrttotal 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 000000010000000000000012drwx------. 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 -lrttotal 4drwx------. 2 postgres postgres 4096 Mar 13 16:52 archive_status[postgres@lyp pg_wal]$

尝试启动数据库

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

重置WAL

    [postgres@lyp pg_wal]$ pg_resetwal $PGDATAThe 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 $PGDATAWrite-ahead log reset[postgres@lyp pg_wal]$ ls -lrttotal 16384drwx------. 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 startwaiting for server to start....2023-03-13 17:04:10.205 CST [20173] LOG:  redirecting log output to logging collector process2023-03-13 17:04:10.205 CST [20173] HINT:  Future log output will appear in directory "log".doneserver started[postgres@lyp pg_wal]$ psqlpsql (14.1)Type "help" for help.postgres=# select * from lxs1;id----12(2 rows)postgres=#

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

重建控制文件

创建测试数据

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

模拟数据库异常

    [postgres@lyp pg_wal]$ ps -ef |grep postgresroot      19555  13684  0 16:49 pts/1    00:00:00 su - postgrespostgres  19556  19555  0 16:49 pts/1    00:00:00 -bashpostgres  19767  19556  0 16:52 pts/1    00:00:00 psqlroot      19790  18013  0 16:53 pts/2    00:00:00 su - postgrespostgres  19791  19790  0 16:53 pts/2    00:00:00 -bashroot      19965  19924  0 16:56 pts/0    00:00:00 su - postgrespostgres  19966  19965  0 16:56 pts/0    00:00:00 -bashpostgres  20013  19966  0 16:56 pts/0    00:00:00 tail -100f postgresql-2023-03-13_072.logpostgres  20272      1  0 17:08 ?        00:00:00 /opt/pgsql14.1/bin/postgrespostgres  20273  20272  0 17:08 ?        00:00:00 postgres: loggerpostgres  20275  20272  0 17:08 ?        00:00:00 postgres: checkpointerpostgres  20276  20272  0 17:08 ?        00:00:00 postgres: background writerpostgres  20277  20272  0 17:08 ?        00:00:00 postgres: walwriterpostgres  20278  20272  0 17:08 ?        00:00:00 postgres: autovacuum launcherpostgres  20279  20272  0 17:08 ?        00:00:00 postgres: archiver failed on 000000010000000000000015postgres  20280  20272  0 17:08 ?        00:00:00 postgres: stats collectorpostgres  20281  20272  0 17:08 ?        00:00:00 postgres: logical replication launcherpostgres  20288  20272  0 17:08 ?        00:00:00 postgres: postgres postgres [local] idlepostgres  20359  19791  0 17:10 pts/2    00:00:00 ps -efpostgres  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 postgresroot      19555  13684  0 16:49 pts/1    00:00:00 su - postgrespostgres  19556  19555  0 16:49 pts/1    00:00:00 -bashpostgres  19767  19556  0 16:52 pts/1    00:00:00 psqlroot      19790  18013  0 16:53 pts/2    00:00:00 su - postgrespostgres  19791  19790  0 16:53 pts/2    00:00:00 -bashroot      19965  19924  0 16:56 pts/0    00:00:00 su - postgrespostgres  19966  19965  0 16:56 pts/0    00:00:00 -bashpostgres  20013  19966  0 16:56 pts/0    00:00:00 tail -100f postgresql-2023-03-13_072.logpostgres  20361  19791  0 17:11 pts/2    00:00:00 ps -efpostgres  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 startpg_ctl: another server might be running; trying to start server anywaywaiting for server to start....2023-03-13 17:13:06.788 CST [20419] PANIC:  could not read file "global/pg_control": read 1 of 296stopped waitingpg_ctl: could not start serverExamine 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 -lrttotal 32768-rw-------. 1 postgres postgres 16777216 Mar 13 17:08 000000010000000000000015drwx------. 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

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

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

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

        postgres@lyp offsets]$ ls -lrttotal 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

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

  [postgres@lyp members]$ ls -rlttotal 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 -rlttotal 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 $PGDATApg_resetwal: error: lock file "postmaster.pid" existspg_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 $PGDATApg_resetwal: warning: pg_control exists but is broken or wrong version; ignoring itGuessed pg_control values:pg_control version number:            1300Catalog version number:               202107181Database system identifier:           7209963927373898017Latest checkpoint's TimeLineID:       1Latest checkpoint's full_page_writes: offLatest checkpoint's NextXID:          0:3Latest checkpoint's NextOID:          12000Latest checkpoint's NextMultiXactId:  1Latest checkpoint's NextMultiOffset:  0Latest checkpoint's oldestXID:        3Latest checkpoint's oldestXID's DB:   0Latest checkpoint's oldestActiveXID:  0Latest checkpoint's oldestMultiXid:   1Latest checkpoint's oldestMulti's DB: 0Latest checkpoint's oldestCommitTsXid:0Latest checkpoint's newestCommitTsXid:0Maximum data alignment:               8Database block size:                  8192Blocks per segment of large relation: 131072WAL block size:                       8192Bytes per WAL segment:                16777216Maximum length of identifiers:        64Maximum columns in an index:          32Maximum size of a TOAST chunk:        1996Size of a large-object chunk:         2048Date/time type storage:               64-bit integersFloat8 argument passing:              by valueData page checksum version:           0Values to be changed:First log segment after reset:        000000010000000000000017NextMultiXactId:                      65536OldestMultiXid:                       65536OldestMulti's DB:                     0NextMultiOffset:                      52352NextXID:                              1048576OldestXID:                            3OldestXID's DB:                       0If 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 -fpg_resetwal: warning: pg_control exists but is broken or wrong version; ignoring itWrite-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 startwaiting for server to start....2023-03-13 17:44:00.209 CST [20785] LOG:  redirecting log output to logging collector process2023-03-13 17:44:00.209 CST [20785] HINT:  Future log output will appear in directory "log".doneserver started[postgres@lyp global]$ psqlpsql (14.1)Type "help" for help.postgres=# select * from lxs1;id----12(2 rows)postgres=#

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

注意

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

PostgreSQL最后的救命稻草 — pg_resetwal相关推荐

被Facebook终止合作，被谷歌下架，股价营收皆腰斩，猎豹只剩AI一根救命稻草了...
郭一璞发自凹非寺量子位报道 | 公众号 QbitAI 有这样一家公司,在移动互联网的时代靠App广告赚钱,各类游戏.各种工具应用做的风生水起. 但在AI时代,流量红利和巨头垄断的困境让它原本的 ...
素质教育，是救命稻草，还是压垮教培机构的最后一根稻草
文|螳螂财经(TanglangFin) 作者| 青月 7月30日晚,高途创始人陈向东发布内部信表示:"为了活下去,公司不得不进行裁员." 据悉,全国13个地方中心,将在8月1日前完 ...
找回创新能力才是苹果的救命稻草
在过去的很多年里,苹果就是创新的代名词.iPod.iPhone以及iPad等,苹果的每一件产品都闪耀着巨大的创新魅力,人们可以不吃饭.不睡觉.半夜排队只为拥有一款苹果的最新产品,创新让苹果风靡世界. ...
“减少风险”还是“管理风险”哪一根才是救命稻草？
在大数据分析为背景的p2p网贷公司迅速崛起2014年二季度,全国P2P网贷成交额554.75元,较一季度增加145.04亿元,增长35.40%.与此同时,伴随着网贷行业的兴起,网贷公司运作上的坏账也一 ...
智能硬件成在线教育救命稻草？
在人口普查结果出来之后,教育行业怎么也没想到监管的重锤会这么快就落在自己的头上.从最开始的风言风语到最后的靴子落地,很多教育机构连喘息的机会都没,就跌入了万丈深渊. 当在线教育机构赖以生存的K9业务被 ...
春节或将成为短信唯一的救命稻草？
春节或将成为短信唯一的救命稻草? 近几年,随着微博.微信.SNS等产品的流行,很多网友发现,手机短信用得越来越少了,以动感地带用户为例,曾几何时,不少用户反映300条短信套餐根本不够用,每个月还得花钱 ...
3星|《财经天下周刊》2017年21期：海外购几乎是亚马逊中国的最后一根救命稻草...
财经天下周刊双周刊 2017年21期第一次看这份杂志.总体评价3星,有一些参考价值. 以下是本期一些内容的摘抄: 1:微软高层亲口宣布放弃WP系统,不过是为早就"脑死亡"的WP ...
经验主义：破解困局的救命稻草
几年前,我曾处理过一个极为"复杂"的技术难题,它耗费了我们足足两个星期的时间,就在所有人都束手无策一筹莫展的时候,一个新的思路破解了困局.在我过往的职业生涯中,遇到过大大小小很多起 ...
数字疗法 | 精神障碍患者的救命稻草
Hello, 这里是壹脑云,我是鸟儿~ 在近期的分享中,我们给大家介绍了妙健康.京东健康等等这些与数字疗法相关的企业. 而本期要给大家分享的是数字疗法在精神健康领域的相关应用~ 数字疗法助力精神健康 ...

PostgreSQL最后的救命稻草 — pg_resetwal

PostgreSQL最后的救命稻草 — pg_resetwal相关推荐

最新文章

热门文章