V2EX › lolizeppelin 的所有回复 › 第 11 页 / 共 49 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 7 8 9 10 11 12 13 14 15 16 ... 49

❮

❯

2021-11-25 15:21:32 +08:00

回复了 chenjiandongx 创建的主题 › 分享创造 › clock: 人生短短数十载来都来了凑活着过吧

焦虑到死啊哈哈哈哈

2021-11-18 01:05:12 +08:00

回复了 TossPig 创建的主题 › 程序员 › 被客户告知 HTTP 的 PUT 请求不安全，甩锅给我们要求整改

30 楼就是标准做法
get 带 body 也是靠这个
参数里加也算是标准写法有些 http 库就直接支持

2021-11-14 09:49:54 +08:00

回复了 KamenReborn 创建的主题 › 奇思妙想 › 这个世界上，总有一些有远见卓识的人能够预知未来

典型的吃别人嚼剩下的东西以为自己也懂了

别人能预见到 10 年 20 年是因为别人有大量的知识储备和大量的思考。
你现在回头看别人的预言觉得逻辑非常清晰,是因为这世界是真按照这样发展的。

但是你没大量的知识储备和思考能力,你以为回到 20 年前你有能判断别人的预言是靠谱的？

2021-11-09 23:42:13 +08:00

回复了 10935336 创建的主题 › Linux › Red Hat Enterprise Linux 9 Beta 已发布 RHEL 9 测试版

基于 fedora 几啊

2021-11-02 16:37:56 +08:00

回复了 lolizeppelin 创建的主题 › JavaScript › crypto-js 的完全看不懂

哦哦原来是这个原因我看看

2021-10-31 20:15:16 +08:00

回复了 O5oz6z3 创建的主题 › Python › 一个小白想法， Python 为什么不通过命令行开关切换两种 GIL 模式？

async 这么多年了都没把全部库搞定
gil 起码搞 10 年

2021-10-24 22:51:06 +08:00

回复了 lolizeppelin 创建的主题 › PostgreSQL › PG11 基于时间点恢复在时间线上无限循环

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

2021-10-04 15:33:01 +08:00

回复了 dtgxx 创建的主题 › Python › 别喷我，真心想求个 Python 工程师的详细路线

后面三个你先把高数复习了
做不到就直接放弃

2021-09-22 14:18:09 +08:00

回复了 s609926202 创建的主题 › 数据库 › MariaDB 遇到个奇怪的现象，空表无缘无故消失、

看 change log 中 bug 修复有没有相关的

用官方稳定版. 10.4 的是 10.4.21

2021-09-21 12:07:02 +08:00

回复了 loveuer 创建的主题 › Angular › Angular 学起来真是太难了，国内资料少，用 G 搜呢，总感觉表达不准确，搜不到好的结果

我真心觉得,水平不行的人用 angluar 才是最好的选择,就是入门麻烦一点点.

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

2021-09-21 11:54:18 +08:00

回复了 wuwukai007 创建的主题 › Python › mysql 如果不存在，插入，还有更快的写法吗？

这种都算邪道....

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

正常业务流程情况下, 发现 update 更新行数不匹配时才 insert
出现大量 update 无匹配应该检查业务流程和代码而不是走捷径

2021-09-17 11:29:01 +08:00

回复了 likeunix 创建的主题 › 分享创造 › 自荐一款 Redis 管理工具

30 块钱还行！买了

2021-09-16 19:16:50 +08:00

回复了 zxCoder 创建的主题 › PostgreSQL › 对于稍微复杂的查询，怎么判断要对哪些字段加索引呢

postgresql 的优化给个只支持 mysql 的工具

2021-09-16 19:10:29 +08:00

回复了 cathedrel 创建的主题 › Linux › 服务器上的程序，以前可以用 user=nobody 的方式跑起来，现在需要读取证书文件，证书文件是 acme.sh 在 root 权限下生成的，如何设置可以让程序以 nobody 权限读取到证书文件跑起来？

楼上说的 fork 以后 setuid 就是最标准的做法

自己翻文档

2021-09-16 19:07:18 +08:00

回复了 dante6733 创建的主题 › Linux › 为什么国内互联网公司喜欢用 Centos 而不是 Ubuntu？

Ubuntu 以前不是号称 Linux 界的 360 么

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

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

话说你们到底想要啥呢 233333

2021-09-15 18:54:55 +08:00

回复了 18870715400 创建的主题 › Python › os.path.isdir 判断目录还是文件出错?

看一眼 os.path.is_dir 的源码不就结了还问半天

2021-09-15 18:53:10 +08:00

回复了 MiketsuSmasher 创建的主题 › Python › Python 有没有更好用的第三方命令行解析库？

openstack 的
oslo_config
包全

2021-09-02 11:34:15 +08:00

回复了 PeterYang1996 创建的主题 › 程序员 › 各位大佬，帮忙看一下这段代码是什么原理让 go 保持后台运行的

找资料学把 fork setsid setuid setgid 和信号搞清楚,别走 cmd 这种邪门歪道

实在不想学你还可以直接用 systemd 来管但是无论怎么搞标准做法还是要处理信号来方便退出

2021-08-24 17:10:58 +08:00

回复了 ghmum 创建的主题 › Windows › 想请教一下， Windows 中的注册表到底是什么？

windows 的注册表里还存了数据的, 不能算单纯的 k/V 配置管理系统

windows 的数据太多了,而且都是大量的实时数据,比如窗口位置,排序方式之类你右键菜单里的乱七八糟的各种配置
linux 里根本不需要这些

2021-08-24 14:08:00 +08:00

回复了 polyang 创建的主题 › 程序员 › 鉴于 github 在国内的网络情况，你们会选择哪个代码托管平台作为替换， gitee、coding 还是 bitbucket？

自建 gitea

1 ... 7 8 9 10 11 12 13 14 15 16 ... 49

❮

❯