2025/04/12 18:50:17
一种查看openGauss中的behavior_compat_options选项支持哪些值的方式:
数据库服务器的数据库运行用户下执行
strings `which gaussdb` | awk '/ustore_unit_test/ {flag=1; next} /set_session_transaction/ {flag=0; exit} flag'
2025/04/11 10:05:43
截止到20250410的ip黑名单
31.7.62.234
36.134.21.102
36.137.195.72
36.140.10.64
36.140.10.145
36.140.160.210
36.140.161.139
36.212.233.36
39.150.130.100
42.177.94.52
43.249.193.47
46.19.142.242
47.92.197.190
49.0.196.81
58.48.96.131
58.53.128.39
58.212.22.130
58.212.22.131
58.221.18.178
60.250.70.187
60.250.70.189
60.250.81.66
79.124.40.94
79.124.56.98
79.124.56.186
79.124.58.158
79.124.58.218
82.156.52.66
83.222.190.78
91.238.181.92
93.123.109.98
103.56.154.146
103.85.168.18
103.148.58.155
103.186.108.229
110.40.47.161
111.10.223.2
111.53.63.134
111.85.83.175
112.2.55.181
112.27.125.137
112.28.149.33
112.51.96.142
112.192.16.55
112.237.143.195
113.140.37.86
114.219.214.47
115.230.124.37
115.239.160.246
116.114.161.15
117.82.91.243
117.90.230.46
117.156.237.76
118.190.103.72
120.41.185.163
120.48.22.39
120.220.44.48
121.12.149.101
123.7.18.116
123.164.144.10
123.182.152.114
124.28.197.138
124.65.97.230
124.79.120.60
124.131.50.55
124.165.238.153
124.232.147.3
124.232.147.204
128.14.98.144
141.255.167.50
150.138.72.54
154.89.10.220
175.6.40.66
175.42.33.95
175.153.161.124
175.153.169.51
180.143.174.169
182.200.3.68
182.200.4.161
182.200.5.77
182.200.6.185
182.200.7.4
182.200.7.20
183.230.200.5
183.239.210.213
183.240.197.189
183.241.138.37
183.249.161.117
183.250.134.17
185.7.214.89
185.42.12.98
185.147.124.102
185.147.124.202
185.147.124.203
192.72.189.195
202.61.86.79
202.101.188.54
210.51.45.106
211.141.173.254
218.17.143.117
218.76.62.187
218.78.122.230
218.85.116.202
218.89.66.58
218.90.122.42
220.78.179.70
220.197.200.154
222.75.100.74
222.79.56.194
222.173.131.58
222.249.238.114
223.13.122.170
223.75.187.13
223.83.10.222
223.108.111.194
223.108.111.238
2025/03/21 15:45:17
gaussdb用shell接收匿名块输出信息(出参)
#!/bin/bash
v=`gsql -r -d postgres -t -q << EOF 2>&1
begin
dbe_output.put_line('aa');
end;
/
\q
EOF`
echo v is $v
2025/03/21 10:49:32
dba_triggers 相关
https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/CREATE-TRIGGER.html
https://docs.oracle.com/en/database/oracle/oracle-database/23/lnpls/CREATE-TRIGGER-statement.html
https://docs.oracle.com/en/database/oracle/oracle-database/23/refrn/ALL_TRIGGERS.html
https://docs.oracle.com/en/database/oracle/oracle-database/18/strms/advanced-apply-process-concepts.html#GUID-BAB09B51-C566-4AD3-BB60-74D69C1D309F
1.ORACLE的触发器body其实除了支持匿名块,也同样支持指定一个procedure,类似于PG的触发器
2.FIRE_ONCE和APPLY_SERVER_ONLY对于存在逻辑备库时能扩展一些使用场景,比如数据脱敏
3.column_name是只有instead of嵌套表的情况下才会有值,常规的触发字段只能从DESCRIPTION这个字符串里解析
2025/02/21 09:36:47
截止到2025-02-20 02:58:19,攻击总算暂时消停了,期间又新增了几个ip在攻击
150.138.72.54
182.200.5.77
182.200.7.20
2025/02/18 17:35:26
今天网络被持续攻击,攻击频率之高令人发指
79.124.40.94 #国外IP,疑似主IP,下面二十几IP都是国内的,疑似肉鸡
123.7.18.116
36.140.10.64
223.108.111.194
112.51.96.142
218.78.122.230
111.10.223.2
115.239.160.246
154.89.10.220
218.17.143.117
175.42.33.95
112.2.55.181
124.28.197.138
223.108.111.238
124.232.147.204
218.85.116.202
222.79.56.194
223.75.187.13
222.75.100.74
112.27.125.137
124.65.97.230
121.12.149.101
历史黑IP
79.124.56.186
141.255.167.50
46.19.142.242
83.222.190.78
31.7.62.234
185.147.124.102
103.186.108.229
175.6.40.66
2025/02/05 10:52:39
在windows terminal里支持上传下载文件
windows terminal
winget install trzsz
linux server
echo '[trzsz]
name=Trzsz Repo
baseurl=https://yum.fury.io/trzsz/
enabled=1
gpgcheck=0' | sudo tee /etc/yum.repos.d/trzsz.repo
sudo yum install trzsz
使用
# 连接(-d开启支持拖拽进去,ssh 可以换成其他ssh工具,比如支持自动保存密码的ssx)
trzsz -d ssh root@192.168.1.1
# 从服务器里下载文件到本地
tsz filename
# 上传文件到服务器
trz
2025/01/28 20:35:53
2025年微软第一坑:
更新WIN10 的 KB5049981 以及 WIN11 的 KB5050009这两个补丁之一 ,会导致部分USB设备无法启动,比如摄像头和耳机。我的视频采集卡在USB3.0协议下就出现了这个问题,设备管理器里显示无法启动,错误代码 10。可笑的是,搜索微软官方解决方案,建议的是更新最新驱动,可是这个问题正是开启了系统更新而导致的。目前的解决方案只能是卸载2025年的这第一个安全补丁。
2025/01/02 17:11:02
字符转数字,如果存在非数字导致报错,根据上下文不同,可能会触发两种不同的报错:
在SQL上下文中,触发 INVALID_NUMBER,
而在PL/SQL上下文中,触发 VALUE_ERROR 异常
而数值精度溢出的报错,无论在SQL还是PLSQL中,触发都是value_error。
但value_error还包含非常多异常情况,比如字符串超长,非法日期格式等。
这两种错误在Gauss中并不能一一对应。
因此gauss上兼容这两个异常,比较通用的方式是,INVALID_NUMBER和VALUE_ERROR都改写成data_exception
2024/12/04 10:29:12
发现一个9年前的坑至今未填,今天撞上了
https://github.com/porcelli/plsql-parser/ 这个项目合并到antlr4里去的时候,把`case when`里一个判断改成了todo,导致无法识别该case when是sql语句中的还是plsql语句中的,关键就是end case中的case是否应该作为别名