From: | Sergei Kornilov <sk(at)zsrv(dot)org> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | dull(dot)bananas0(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com> |
Subject: | Re: BUG #19018: high memory usage and "stack depth limit exceeded", with GiST index on ltree |
Date: | 2025-08-14 09:22:36 |
Message-ID: | 736361755163356@mail-sendbernar-production-main-67.sas.yp-c.yandex.net |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hello
This reminded me of some very old bug reports, like mine: https://www.postgresql.org/message-id/15431-7a89470f7879bed4%40postgresql.org
Still reproduces giving different results depending on the order of operations. The proposed patch makes the behavior the same in both cases.
Since this code path may be reachable by the user, instead of elog there should be ereport with a more user-friendly description. I would suggest something more like the text used for btree in a case like this. (ereport in _bt_check_third_page)
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("index row size %zu exceeds gist maximum %zu for index \"%s\""...
errdetail("Index row references tuple (%u,%u) in relation \"%s\".",...
errhint("Values larger than 1/2 of a buffer page cannot be indexed"...
regards, Sergei
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2025-08-14 11:02:29 | Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database |
Previous Message | Amit Kapila | 2025-08-14 08:48:27 | Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database |