Re: Failure to create GiST on ltree column

From: Victor Yegorov <vyegorov(at)gmail(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Failure to create GiST on ltree column
Date: 2020-05-25 13:41:49
Message-ID: CAGnEboheXWNhpB0OhAuGwFmm3XVBSGUo7eCj1u1qLUWdb8cKaw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

пн, 25 мая 2020 г. в 01:52, Justin Pryzby <pryzby(at)telsasoft(dot)com>:

> I think you'd want to attach a debugger to the backend's PID and set
> breakpoint
> on errfinish() or pg_re_throw() and reproduce the problem to get a
> stacktrace
> (separate stacks for both errors).
>
> https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

Thanks. I'm attaching 2 backtraces.
Big one is for the “stack depth limit exceeded” case.

After I set max_stack_depth to the maximum possible value,
I am getting “failed to add item to index page” errors.

What is value of maintenance_work_mem ?
>

1GB

What's the definition of the index and relevant table columns ?
>

# \d comments.mp_comments
Table
"comments.mp_comments"
Column | Type | Collation |
Nullable | Default
---------------------------+--------------------------+-----------+----------+--------------------------------------------------------------
obj_id | bigint | | not
null | (nextval('comments.comments_obj_id_seq'::regclass))::numeric
obj_created | timestamp with time zone | | not
null | now()
obj_modified | timestamp with time zone | | not
null | now()
obj_status_did | smallint | | not
null | 1
c_comment | character varying | | not
null |
mpath | ltree | | not
null |
c_person_obj_id | bigint | | not
null |
c_lcid | character varying | |
| 32
c_rating | double precision | | not
null | 0
c_mpath_level | bigint | | not
null | 1
c_root_obj_id | bigint | | not
null |
c_root_obj_type | smallint | |
|
c_parent_obj_id | bigint | |
|
c_root_obj_vislvl_content | smallint | | not
null | 9
c_forecast_bias | smallint | |
|
mpath_array | bigint[] | |
|
anonymous | boolean | | not
null | false
c_edited | smallint | |
|
c_edited_at | timestamp with time zone | |
|
c_image | character varying(255) | |
|
c_from_mobile | boolean | |
|
Indexes:
"mpath_pkey" PRIMARY KEY, btree (obj_id)
"i_mp_comments_mpath_btree" UNIQUE, btree (mpath)
"i_comment_c_comment_ts_vector" gin (make_tsvector(c_comment::text,
'russian'::text))
"i_comment_mp_comments_person_created" btree (c_person_obj_id,
obj_status_did, obj_created)
Inherits: obj_base

New index to be created:
CREATE INDEX i_mp_comments_mpath_gist ON comments.mp_comments USING gist
(mpath);

Do you know if that was that an issue under 11.7 as well ?
>

It was an issue on the 11.2, I've updated to the latest minor release, no
changes.

Are you running on any interesting hardware ?
>

Nothing fancy, no VM.

--
Victor Yegorov

Attachment Content-Type Size
failed_to_add_item_to_index_page_gdb.txt text/plain 3.1 KB
max_stack_depth_gdb.txt.gz application/x-gzip 122.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-05-25 13:43:32 Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Previous Message Peter Eisentraut 2020-05-25 13:28:54 Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch