Обсуждение: [HACKERS] uninterruptible state in 10beta4
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 <pid> from another terminal.
I have to do kill -9 <pid>
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 <andres@anarazel.de>
Date: Tue Jul 25 17:37:17 2017 -0700
Move interrupt checking from ExecProcNode() to executor nodes.
#0 0x0000003e4e8db7d0 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
#1 0x00000000004ef3e1 in XLogFileInit (logsegno=189, use_existent=0x7ffe52b505df "\001", use_lock=1 '\001') at xlog.c:3222
#2 0x00000000004f15e8 in XLogWrite (WriteRqst=..., flexible=0 '\000') at xlog.c:2408
#3 0x00000000004f1d89 in AdvanceXLInsertBuffer (upto=3175088128, opportunistic=<value optimized out>) at xlog.c:2114
#4 0x00000000004f1e99 in GetXLogBuffer (ptr=3175088128) at xlog.c:1879
#5 0x00000000004f79fe in CopyXLogRecordToWAL (rdata=0xc921f0, fpw_lsn=<value optimized out>, flags=1 '\001') at xlog.c:1498
#6 XLogInsertRecord (rdata=0xc921f0, fpw_lsn=<value optimized out>, flags=1 '\001') at xlog.c:1073
#7 0x00000000004fb40b in XLogInsert (rmid=10 '\n', info=0 '\000') at xloginsert.c:462
#8 0x00000000004af8fd in heap_insert (relation=0x7f1456e7be58, tup=0x7f14568e12d8, cid=<value optimized out>, options=<value optimized out>,
bistate=<value optimized out>) at heapam.c:2537
#9 0x000000000060db9f in ExecInsert (node=0x14f44b8) at nodeModifyTable.c:601
#10 ExecModifyTable (node=0x14f44b8) at nodeModifyTable.c:1741
#11 0x00000000005f4ef8 in ExecProcNode (node=0x14f44b8) at execProcnode.c:422
#12 0x00000000005f1d76 in ExecutePlan (queryDesc=0x1442bb8, direction=<value optimized out>, count=0, execute_once=-72 '\270') at execMain.c:1693
#13 standard_ExecutorRun (queryDesc=0x1442bb8, direction=<value optimized out>, count=0, execute_once=-72 '\270') at execMain.c:362
#14 0x000000000071c95b in ProcessQuery (plan=<value optimized out>, sourceText=0x149d018 "insert into foo select * from generate_series(1,100000000);",
params=0x0, queryEnv=0x0, dest=<value optimized out>, completionTag=0x7ffe52b50cc0 "") at pquery.c:161
#15 0x000000000071cb95 in PortalRunMulti (portal=0x14caea8, isTopLevel=1 '\001', setHoldSnapshot=0 '\000', dest=0x14f0ca8, altdest=0x14f0ca8,
completionTag=0x7ffe52b50cc0 "") at pquery.c:1286
#16 0x000000000071d260 in PortalRun (portal=0x14caea8, count=9223372036854775807, isTopLevel=1 '\001', run_once=1 '\001', dest=0x14f0ca8,
altdest=0x14f0ca8, completionTag=0x7ffe52b50cc0 "") at pquery.c:799
#17 0x0000000000719987 in exec_simple_query (query_string=0x149d018 "insert into foo select * from generate_series(1,100000000);") at postgres.c:1099
#18 0x000000000071a8c9 in PostgresMain (argc=<value optimized out>, argv=<value optimized out>, dbname=0x14473c0 "jjanes", username=<value optimized out>)
at postgres.c:4090
#19 0x00000000006aff4a in BackendRun (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:4357
#20 BackendStartup (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:4029
#21 ServerLoop (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:1753
#22 PostmasterMain (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:1361
#23 0x0000000000631410 in main (argc=1, argv=0x141c2f0) at main.c:228
Cheers,
Jeff
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 <pid> from another > terminal. > > I have to do kill -9 <pid> > > 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 <andres@anarazel.de> > 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
Вложения
On Wed, Sep 13, 2017 at 2:41 PM, Andres Freund <andres@anarazel.de> wrote:
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 <pid> from another
> terminal.
>
> I have to do kill -9 <pid>
>
> 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 <andres@anarazel.de>
> 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?
Yep, that fixes it.
Thanks,
Jeff
Jeff Janes <jeff.janes@gmail.com> writes:
> 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 <pid> from another
> terminal.
Hm, I suspect the culprit is that the fast path out of ExecScan()
fails to include a CHECK_FOR_INTERRUPTS. It might be best to take
the CHECK_FOR_INTERRUPTS at line 160 and put it into ExecScanFetch
instead (but if so, that function's comment could use adjustment).
Andres?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Indeed that seems plausible. I guess something like the attached should
> fix the issue?
Ah, I see you came to the same conclusion I did. But see comment
about adding a comment.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-09-13 14:46:08 -0700, Jeff Janes wrote: > On Wed, Sep 13, 2017 at 2:41 PM, Andres Freund <andres@anarazel.de> wrote: > > Indeed that seems plausible. I guess something like the attached should > > fix the issue? > > > > Yep, that fixes it. Cool. Pushed. Thanks for the report! Thanks, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-09-13 17:53:44 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Indeed that seems plausible. I guess something like the attached should > > fix the issue? > > Ah, I see you came to the same conclusion I did. But see comment > about adding a comment. I've pushed something - Not sure if you'd anything else in mind WRT comment... 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