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 |
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 |