Re: autovacuum process (PID ...) was terminated by signal 11
От | Brian Hirt |
---|---|
Тема | Re: autovacuum process (PID ...) was terminated by signal 11 |
Дата | |
Msg-id | F9297AE6-7506-42C8-8B9C-A2E5E9871D20@mobygames.com обсуждение исходный текст |
Ответ на | Re: autovacuum process (PID ...) was terminated by signal 11 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: autovacuum process (PID ...) was terminated by signal 11
|
Список | pgsql-bugs |
Tom, I can analyze that table without problems. I don't know if it's the same table every time. I'm trying to set up a development environment where i can test this stuff better without messing up our production systems. The table does have an expresional index. basement=# select relname from pg_class where oid = 32465292; relname --------------- developer_aka (1 row) basement=# ANALYZE verbose developer_aka; ANALYZE basement=# \d developer_aka Table "public.developer_aka" Column | Type | Modifiers ------------------+------------------------ +---------------------------------------------------------------- developer_id | integer | developer_aka_id | integer | not null default nextval (('developer_id_seq'::text)::regclass) first_name | character varying(255) | last_name | character varying(255) | search_name | character varying(255) | Indexes: "developer_aka_pkey" PRIMARY KEY, btree (developer_aka_id) "developer_aka_developer_id_inde" btree (developer_id) "developer_aka_name_idx" btree (name_idx(first_name, last_name)) "developer_aka_search" btree (search_name) Foreign-key constraints: "$1" FOREIGN KEY (developer_id) REFERENCES developer(developer_id) Triggers: developer_modified AFTER INSERT OR UPDATE ON developer_aka FOR EACH ROW EXECUTE PROCEDURE add_developer_mod() function definition: CREATE FUNCTION name_idx(character varying, character varying) RETURNS character varying AS $_$ DECLARE n varchar; BEGIN select upper($1) || ' ' || upper($2) into n; return n; END; $_$ LANGUAGE plpgsql IMMUTABLE; --brian On Jan 4, 2006, at 10:25 AM, Tom Lane wrote: > Brian Hirt <bhirt@mobygames.com> writes: >> Is there more information i can provide to help find the problem? > > How about the schema of the table in question? If the backtrace is > to be trusted, it's OID 32465292. > > Does it crash if you ANALYZE that table manually? > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -------------------------------------------- MobyGames http://www.mobygames.com The world's largest and most comprehensive gaming database project
В списке pgsql-bugs по дате отправления: