Re: [HACKERS] uninterruptible state in 10beta4
От
Andres Freund
Тема
Re: [HACKERS] uninterruptible state in 10beta4
Дата
Msg-id
20170913214137.ku6f4ciuapeg27ts@alap3.anarazel.de
Ответ на
[HACKERS] uninterruptible state in 10beta4 (Jeff Janes)
Список
Дерево обсуждения
[HACKERS] uninterruptible state in 10beta4 Jeff Janes <jeff.janes@gmail.com>
Re: [HACKERS] uninterruptible state in 10beta4 Andres Freund <andres@anarazel.de>
Re: [HACKERS] uninterruptible state in 10beta4 Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] uninterruptible state in 10beta4 Andres Freund <andres@anarazel.de>
Re: [HACKERS] uninterruptible state in 10beta4 Jeff Janes <jeff.janes@gmail.com>
Re: [HACKERS] uninterruptible state in 10beta4 Andres Freund <andres@anarazel.de>
Re: [HACKERS] uninterruptible state in 10beta4 Tom Lane <tgl@sss.pgh.pa.us>
Hi, On 2017-09-13 14:28:34 -0700, Jeff Janes wrote: > In 10beta4 and 11dev, If I run the below it enters an uninterruptible > state. After the insert starts, I give 15 or seconds or so until the > memory usage starts to grow due to enqueued triggers checks. Then I can't > interrupt it with either ctrl-C in psql or kill -15 from another > terminal. > > I have to do kill -9 > > create table foo (x int); > create or replace function notice () returns trigger as $$ begin raise > notice 'asdfsdf'; return NEW; END;$$ language plpgsql; > create trigger foobar after insert on foo for each row execute procedure > notice(); > insert into foo select * from generate_series(1,100000000); > > Git bisect lays the blame here which certainly seems plausible: > > commit d47cfef7116fb36349949f5c757aa2112c249804 > Author: Andres Freund > Date: Tue Jul 25 17:37:17 2017 -0700 > > Move interrupt checking from ExecProcNode() to executor nodes. Indeed that seems plausible. I guess something like the attached should fix the issue? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления
От: Thomas Munro
Дата: