lolizeppelin 最近的时间轴更新
lolizeppelin

lolizeppelin

V2EX 第 239732 号会员,加入于 2017-07-11 18:20:07 +08:00
今日活跃度排名 19951
被各种关系数据库的 json 操作坑死了
Python  •  lolizeppelin  •  2020-09-04 09:39:30 AM  •  最后回复来自 ghostviper
32
有没有熟悉 libtorrent 或者 bt 客户端开发的
程序员  •  lolizeppelin  •  2020-03-05 10:36:59 AM  •  最后回复来自 julyclyde
10
求个完美的文件夹校验正则
程序员  •  lolizeppelin  •  2020-02-18 20:05:50 PM  •  最后回复来自 no1xsyzy
19
有没有熟悉 setuptool 和 pbr 的同学?
Python  •  lolizeppelin  •  2019-09-10 15:48:41 PM  •  最后回复来自 lolizeppelin
1
求一个编译号的 Python 包 yappi 要 python3.6 的
Python  •  lolizeppelin  •  2019-09-02 16:34:04 PM  •  最后回复来自 Pzqqt
2
DBA 脑子要咋长才行啊....
数据库  •  lolizeppelin  •  2019-07-11 10:36:37 AM  •  最后回复来自 CallMeReznov
1
TimescaleDB 不支持并行查询?
PostgreSQL  •  lolizeppelin  •  2019-07-06 20:14:20 PM  •  最后回复来自 lolizeppelin
6
mysql 8.0 为什么那么大? 800M 的可执行文件
MySQL  •  lolizeppelin  •  2019-06-26 17:12:14 PM  •  最后回复来自 lolizeppelin
15
lolizeppelin 最近回复了
debug5 级别日志



2021-10-24 22:49:09.874 CST [4514] LOG: database system was shut down in recovery at 2021-10-24 22:30:59 CST
2021-10-24 22:49:09.874 CST [4514] DEBUG: restore_command = '/usr/bin/lz4 -f -q -d /data/database/1/backup/%f.lz4 %p'
2021-10-24 22:49:09.874 CST [4514] DEBUG: recovery_target_action = 'promote'
2021-10-24 22:49:09.874 CST [4514] DEBUG: recovery_target_inclusive = false
2021-10-24 22:49:09.875 CST [4514] DEBUG: recovery_target_time = '2021-10-24 17:19:00+08'
2021-10-24 22:49:09.875 CST [4514] LOG: starting point-in-time recovery to 2021-10-24 17:19:00+08
2021-10-24 22:49:09.875 CST [4514] DEBUG: executing restore command "/usr/bin/lz4 -f -q -d /data/database/1/backup/000000010000000200000023.lz4 pg_wal/RECOVERYXLOG"
2021-10-24 22:49:09.910 CST [4514] LOG: restored log file "000000010000000200000023" from archive
2021-10-24 22:49:09.912 CST [4514] DEBUG: got WAL segment from archive
2021-10-24 22:49:09.912 CST [4514] DEBUG: checkpoint record is at 2/23001C18
2021-10-24 22:49:09.913 CST [4514] DEBUG: redo record is at 2/23001BE0; shutdown false
2021-10-24 22:49:09.913 CST [4514] DEBUG: next transaction ID: 0:4735090; next OID: 34298
2021-10-24 22:49:09.913 CST [4514] DEBUG: next MultiXactId: 1; next MultiXactOffset: 0
2021-10-24 22:49:09.913 CST [4514] DEBUG: oldest unfrozen transaction ID: 562, in database 1
2021-10-24 22:49:09.913 CST [4514] DEBUG: oldest MultiXactId: 1, in database 1
2021-10-24 22:49:09.913 CST [4514] DEBUG: commit timestamp Xid oldest/newest: 0/0
2021-10-24 22:49:09.913 CST [4514] DEBUG: transaction ID wrap limit is 2147484209, limited by database with OID 1
2021-10-24 22:49:09.913 CST [4514] DEBUG: MultiXactId wrap limit is 2147483648, limited by database with OID 1
2021-10-24 22:49:09.913 CST [4514] DEBUG: starting up replication slots
2021-10-24 22:49:09.913 CST [4514] DEBUG: starting up replication origin progress state
2021-10-24 22:49:09.914 CST [4514] DEBUG: resetting unlogged relations: cleanup 1 init 0
2021-10-24 22:49:09.916 CST [4514] DEBUG: initializing for hot standby
2021-10-24 22:49:09.916 CST [4514] DEBUG: my backend ID is 1
2021-10-24 22:49:09.916 CST [4514] LOG: redo starts at 2/23001BE0
2021-10-24 22:49:09.916 CST [4514] DEBUG: prune KnownAssignedXids to 4735090
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001BE0 for Standby/RUNNING_XACTS: nextXid 4735090 latestCompletedXid 4735089 oldestRunningXid 4735090
2021-10-24 22:49:09.916 CST [4514] DEBUG: 0 KnownAssignedXids (num=0 tail=0 head=0)
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001BE0 for Standby/RUNNING_XACTS: nextXid 4735090 latestCompletedXid 4735089 oldestRunningXid 4735090
2021-10-24 22:49:09.916 CST [4514] DEBUG: recovery snapshots are now enabled
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001BE0 for Standby/RUNNING_XACTS: nextXid 4735090 latestCompletedXid 4735089 oldestRunningXid 4735090
2021-10-24 22:49:09.916 CST [4514] DEBUG: prune KnownAssignedXids to 4735090
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001C88 for Standby/RUNNING_XACTS: nextXid 4735090 latestCompletedXid 4735089 oldestRunningXid 4735090
2021-10-24 22:49:09.916 CST [4514] DEBUG: record known xact 4735090 latestObservedXid 4735089
2021-10-24 22:49:09.916 CST [4514] CONTEXT: WAL redo at 2/23001CC0 for Heap/DELETE: off 2 KEYS_UPDATED
2021-10-24 22:49:09.917 CST [4514] LOG: consistent recovery state reached at 2/230029E8
2021-10-24 22:49:09.917 CST [4514] LOG: recovery stopping before commit of transaction 4735090, time 2021-10-24 17:44:51.300459+08
2021-10-24 22:49:09.917 CST [4514] LOG: redo done at 2/230029E8
2021-10-24 22:49:09.917 CST [4514] DEBUG: resetting unlogged relations: cleanup 0 init 1
2021-10-24 22:49:09.918 CST [4512] LOG: database system is ready to accept read only connections
2021-10-24 22:49:09.918 CST [4516] DEBUG: checkpointer updated shared memory configuration values
2021-10-24 22:49:09.919 CST [4514] DEBUG: executing restore command "/usr/bin/lz4 -f -q -d /data/database/1/backup/00000002.history.lz4 pg_wal/RECOVERYHISTORY"
/data/database/1/backup/00000002.history.lz4: No such file or directory
2021-10-24 22:49:09.926 CST [4514] LOG: restored log file "00000002.history" from archive
2021-10-24 22:49:09.926 CST [4514] DEBUG: executing restore command "/usr/bin/lz4 -f -q -d /data/database/1/backup/00000003.history.lz4 pg_wal/RECOVERYHISTORY"
/data/database/1/backup/00000003.history.lz4: No such file or directory
2021-10-24 22:49:09.933 CST [4514] LOG: restored log file "00000003.history" from archive
2021-10-24 22:49:09.933 CST [4514] DEBUG: executing restore command "/usr/bin/lz4 -f -q -d /data/database/1/backup/00000004.history.lz4 pg_wal/RECOVERYHISTORY"


后面就是无限循环找时间线....orz
22 天前
回复了 dtgxx 创建的主题 Python 别喷我,真心想求个 Python 工程师的详细路线
后面三个你先把高数复习了
做不到就直接放弃
我真心觉得,水平不行的人用 angluar 才是最好的选择,就是入门麻烦一点点.

对比之前写的 react 代码,发现我自己这种水平完全把控不住代码写着写着就瞎几把写了
反观 angluar..真是清清楚楚.就是啰啰嗦嗦不漂亮
这种都算邪道....

正常业务新增和更新本来就是分开的

正常业务流程情况下, 发现 update 更新行数不匹配时才 insert
出现大量 update 无匹配应该检查业务流程和代码而不是走捷径
39 天前
回复了 likeunix 创建的主题 分享创造 自荐一款 Redis 管理工具
30 块钱还行! 买了
postgresql 的优化给个只支持 mysql 的工具
楼上说的 fork 以后 setuid 就是最标准的做法

自己翻文档
Ubuntu 以前不是号称 Linux 界的 360 么

话说 redhat/centos 的大版本是完全不改 linux 内核版本的,后续所有东西都以补丁形式由红帽追加,导致所有包版本都旧得 1b 。

centos8 开始玩滚动更新了一堆人又开骂.....

话说你们到底想要啥呢 233333
41 天前
回复了 18870715400 创建的主题 Python os.path.isdir 判断目录还是文件出错?
看一眼 os.path.is_dir 的源码不就结了 还问半天
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1068 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 27ms · UTC 22:07 · PVG 06:07 · LAX 15:07 · JFK 18:07
♥ Do have faith in what you're doing.