通过级别和kill-9的套接字故障来窥视内核
Kill-9-signalling 所有 postgres 进程在命令后立即引发错误：
$ psql
psql: could not connect to server: Connection refused
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
长期计算机科学问题
测试的目的是模拟一个严重的致命错误，由于套接字故障而窥视内核。在崩溃恢复等情况下这是一个很好的做法。
- 它与 x86 的级别（零级和三级）有关吗？
- 9杀对kernel、fs等东西做了什么？
- 插座有什么问题？
- 在信号传输过程中，文件发生了什么与副作用相关的情况？
Kill-9-signalling all postgres processes ignite errors immediately after the command:
$ psql
psql: could not connect to server: Connection refused
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
Long-term Computer Science problem
The aim of the test is to simulate a serious fatal error, peeking into kernel due to the socket failure. It is good practise in cases such as crash-recovery.
- Does it have something to do with the levels, zero and three, of x86?
- What did the 9-killing do to things such as kernel and fs?
- What is wrong with the socket?
- What did happen to files during the signaling, related to side effects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这更像是一种服务器故障类型的问题，但尝试像这样运行 psql：
当您安装 PostgreSQL 时，没有为当前用户创建用户帐户，因此您必须创建一个。
可以这样实现（其中masi是想要的用户名）：
This more a Server Fault kind of question, but try running psql like this:
When you install PostgreSQL, there's no user account created for your current user, so you'd have to create one.
That can be achieved like this (where masi is the wanted username):
不。
什么都没有——尽管 postgresql 的数据库文件可能处于不一致的状态。
没有（？）。
向进程发送信号 9 只是强制其立即退出。对于数据库服务器来说，如果它正在更改数据文件/存储，则可能会有点致命 - 使它们处于不一致的状态。
听起来您要么没有从旧的 postgresql 安装中删除所有内容，要么在重新安装后没有正确配置服务器。
No.
Nothing - though the database files of postgresql might have been left in an inconsistent state.
No (?).
Sending signal 9 to a process simply forces it to exit immediately. For a database server that can be a bit fatal if it was in the middle of altering the data files/storage - leaving them in an inconsistent state.
It sounds like you either haven't removed everything from your old postgresql installation, or you haven't configured the server properly after reinstalling it.