uninterruptible state in 10beta4

Started by Jeff Janesover 8 years ago7 messages

jeff.janes@gmail.com

over 8 years ago

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

Andres Freund

andres@anarazel.de

over 8 years ago

In reply to: Jeff Janes (#1)

1 attachment(s)

Re: uninterruptible state in 10beta4

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

Attachments:

cfi.difftext/x-diff; charset=us-asciiDownload

diff --git a/src/backend/executor/execScan.c b/src/backend/executor/execScan.c
index 47a34a044a..3fec198589 100644
--- a/src/backend/executor/execScan.c
+++ b/src/backend/executor/execScan.c
@@ -40,6 +40,8 @@ ExecScanFetch(ScanState *node,
 {
 	EState	   *estate = node->ps.state;
 
+	CHECK_FOR_INTERRUPTS();
+
 	if (estate->es_epqTuple != NULL)
 	{
 		/*
@@ -157,8 +159,6 @@ ExecScan(ScanState *node,
 	{
 		TupleTableSlot *slot;
 
-		CHECK_FOR_INTERRUPTS();
-
 		slot = ExecScanFetch(node, accessMtd, recheckMtd);
 
 		/*

Jeff Janes

jeff.janes@gmail.com

over 8 years ago

In reply to: Andres Freund (#2)

Re: uninterruptible state in 10beta4

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

Tom Lane

tgl@sss.pgh.pa.us

over 8 years ago

In reply to: Jeff Janes (#1)

Re: uninterruptible state in 10beta4

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

Tom Lane

tgl@sss.pgh.pa.us

over 8 years ago

In reply to: Andres Freund (#2)

Re: uninterruptible state in 10beta4

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

Andres Freund

andres@anarazel.de

over 8 years ago

In reply to: Jeff Janes (#3)

Re: uninterruptible state in 10beta4

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

Andres Freund

andres@anarazel.de

over 8 years ago

In reply to: Tom Lane (#5)

Re: uninterruptible state in 10beta4

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