【问题标题】:max_stack_depth error in postgresqlpostgresql 中的 max_stack_depth 错误
【发布时间】:2012-08-01 21:29:07
【问题描述】:

我创建触发器来存储工资金额,但是当我触发插入查询时

INSERT INTO employees(
            employee_id, first_name, last_name, email, phone_number,  hire_date, 
            job_id, salary, commission_pct, manager_id, department_id)
    VALUES (2002,'poiuy','patel','bhargavgor@dfghj',9898562123,'2012-07-31 00:00:00','IT_PROG',4500.00,0.00,100,60);

然后它会显示以下错误来设置max_stack_depth的限制所以任何人都可以给我解决这个错误的想法..

我也尝试更改配置文件中max_stack_depth 的值,但它不起作用

如下错误

ERROR:  stack depth limit exceeded
HINT:  Increase the configuration parameter "max_stack_depth" (currently 2048kB), after ensuring the platform's stack depth limit is adequate.

【问题讨论】:

  • 我没有看到触发器。也许你也应该向我们展示它的来源。 (触发函数是递归的吗?)

标签: database postgresql


【解决方案1】:

我会说您在employees 上有一个ON INSERT OR UPDATE 触发器,它直接或间接地对employees 表执行UPDATE,而不检查它是直接调用还是通过触发器调用。

这通常是一个编程错误,您在employee 表上执行UPDATE,而不是让您的BEFORE INSERT OR UPDATE ... FOR EACH ROW 触发器修改NEW 的值。

有时是两个触发器之间的相互递归,比较难处理。不幸的是,我不知道有什么方法可以检测触发器是由直接客户端语句调用还是通过另一个存储的过程或触发器调用的。通常需要进行设计更改以避免相互递归。

Prevent recursive trigger in PostgreSQL

【讨论】:

  • 这里:stackoverflow.com/a/11702666/905902,我使用了一个 per row 布尔标志来避免雪崩级联(这是一种巧妙的技巧,有时可能很有用)。我检查了文档以查看是否有任何魔术变量来判断是否从触发器中执行了某些函数。没有。
  • 但是对于希望增加 max_stack_depth 的人来说,他们将如何更改设置?
  • @bWilliamson 如果需要,您可能做错了什么。 PostgreSQL 不太适合深度递归调用,您应该重构以使用迭代模型,或者最好使用更多的关系集操作。看看递归 CTE(实际上是迭代的),即WITH RECURSIVE,是否可以帮助你。
【解决方案2】:

您能否发布更改 max_stack_depth 时收到的错误消息。

linux 系统中的“ulimit -s”将给出堆栈深度。 将 max_stack_depth 设置为比您的实际服务器限制(ulimit -s)小一或二。

设置后请重新加载。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-04-03
    • 1970-01-01
    • 2020-07-25
    • 2010-12-26
    相关资源
    最近更新 更多