有什么方法可以中断 Windows Server 2008 中 PostgreSQL 8.4 中丢失或空闲的 TCP/IP 连接吗?

发布于 2024-09-12 08:42:45 字数 517 浏览 10 评论 0原文

我问过:如何通过 keepalive postgreSQL 断开 TCP/IP 连接而不更改寄存器中的任何内容?

现在,我想确认:

我的系统(C#.NET、NHibernate 和 Active Record)正在与数据库一起运行PostgreSQL 8.4 和 Windows 服务器。我需要一种方法来中断空闲或丢失的 TCP/IP 连接并解锁数据。

我无法调整操作系统配置,也无法重新编译 PostgreSQL。如果需要,我的系统可以在 Oracle 10g Express 中运行!我需要知道:我可以在不为 PostgreSQL 实施新补丁的情况下中断空闲连接吗?为此,我是否需要将数据库迁移到 Oracle?

谢谢,

I've asked: How to break connections TCP/IP by keepalive postgreSQL without changing anything in the register?

And now, I want to confirm:

My system (C#.NET, NHibernate and Active Record) is running with a database PostgreSQL 8.4 and a Windows Server. I need a way to break idle or lost TCP/IP connections and unblock data.

I can't tweak OS configs nor recompile the PostgreSQL. My system can run in Oracle 10g Express if needed! I need to know: Can I break idle conections without implement a new patch for PostgreSQL? Do I need to migrate my database to Oracle for that?

Thanks,

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

前事休说 2024-09-19 08:42:45

如果有办法强制每个新连接在连接时执行查询,您可以编写一个数据库函数,为符合某些条件的任何进程动态调用“pg_terminate_backend(pid)”。在不知道您的设置的情况下,一些可能性是:

  • current_query = ' in transaction' 和 CURRENT_TIMESTAMP - query_start() 大于某个值(1 分钟?5 分钟?)的
  • 连接 来自您的 IP 地址或个人用户名(如果存在)的连接目前尚未使用(不过,在连接池环境中可能不是一个好主意)就

我个人而言,我会尝试进行重构,以最大限度地减少任何事务可能打开的时间。在某些地方,您可能会不必要地打开事务,从而导致触发问题的可能性增加:

  • ORM 正在运行,而 AutoCommit 已关闭。
  • 当为编辑屏幕读取数据时会采取锁定,因此数据在写回之前无法更新。在回写之前验证不存在冲突可能是可以接受的。
  • 事务在非数据库任务(例如 FTP 或电子邮件进程)之前启动,然后在之后关闭。
  • 第一个语句是不带锁定子句的 SELECT 的事务(如“FOR UPDATE”)。无论是在事务内部还是事务外部,此 SELECT 的结果都是相同的,因此这表明事务开始得太早并且可以缩短。
  • 仅包含任何类型的一项语句的交易。

If there's a way to force each new connection to execute a query at connect time, you could write a database function that dynamically calls "pg_terminate_backend(pid)" for any processes that are in some criteria. Without knowing your setup, some possibilities are:

  • Connections with current_query = ' in transaction' and CURRENT_TIMESTAMP - query_start() greater than some value (1 minute? 5 minutes?)
  • Connections from your IP address or individual user name (if exists) that you aren't currently using (probably not a good idea in connection-pooling environments, though)

Personally, I would try and refactor in order to minimize the amount of time any transaction can possibly be open. Some places where you may have a transaction open unnecessarily, resulting in an increased chance of triggering your problem:

  • An ORM is running with AutoCommit turned off.
  • A LOCK is taken when data is read for an edit screen so the data cannot be updated before it is written back. It may be acceptable to verify before writing back that there's no conflict.
  • Transactions started before a non-database task, like an FTP or Email process, then closed afterwards.
  • Transactions where the very first statement is a SELECT without a locking clause (like "FOR UPDATE"). The result of this SELECT will be the same whether it is inside or outside the transaction, so it's an indicator that the transaction was started too early and could be shortened.
  • Transactions that only contain one statement of any kind.
兔姬 2024-09-19 08:42:45

您正在寻找 pg_cancel_backend() 或 pg_terminate_backend() ?

检查 http://www.postgresql.org/docs/current/static /functions-admin.html

You're looking for pg_cancel_backend() or pg_terminate_backend() ?

Check http://www.postgresql.org/docs/current/static/functions-admin.html

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文