V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lolizeppelin  ›  全部回复第 15 页 / 共 53 页
回复总数  1056
1 ... 11  12  13  14  15  16  17  18  19  20 ... 53  
2021-12-10 18:11:33 +08:00
回复了 Wsdba 创建的主题 Java 大家帮我看看,这代码是水平。。
逻辑确实有问题
这里逻辑确实可以简化
mb1 != mb2 && mb1!=null return true
return false
2021-12-09 11:55:37 +08:00
回复了 AngryElephant 创建的主题 云计算 原互联网业务码农,现在面临选择问题
openstack 照着它模型写也是 curd 吧
写具体业务实现部分你得要知道的是具体落地操作
这就要熟悉 linux 以及网络相关知识
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 的完全看不懂
哦哦 原来是这个原因 我看看
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
我真心觉得,水平不行的人用 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 的工具
楼上说的 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
包全
找资料学把 fork setsid setuid setgid 和信号 搞清楚,别走 cmd 这种邪门歪道

实在不想学你还可以直接用 systemd 来管 但是无论怎么搞 标准做法还是要处理信号来方便退出
1 ... 11  12  13  14  15  16  17  18  19  20 ... 53  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   6027 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 86ms · UTC 02:08 · PVG 10:08 · LAX 18:08 · JFK 21:08
Developed with CodeLauncher
♥ Do have faith in what you're doing.