LLVM jit and window functions on a temporary table

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема LLVM jit and window functions on a temporary table
Дата
Msg-id CA+q6zcUq2VKFBwgk42Qg2hz-=62c1cB1MCBV6Ocwtj__9=RWtQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: LLVM jit and window functions on a temporary table  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Hi,

While testing PostgreSQL instance with enabled jit I found out another
interesting problem:

# postgresql.conf
jit = on
jit_above_cost = 0

=# create temp table t1 (f1 int, f2 int8);
=# insert into t1 values (1,1),(1,2),(2,2);

=# select f1, sum(f1) over (partition by f1 order by f2
                         range between 1 preceding and 1 following)
from t1 where f1 = f2;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

gdb shows that in tuplestore_select_read_pointer somehow the value of ptr is -1

>>> bt
#0  0x00007ff50d390428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ff50d39202a in __GI_abort () at abort.c:89
#2  0x00000000008b3397 in ExceptionalCondition
(conditionName=conditionName@entry=0xadf4c0 "!(ptr >= 0 && ptr <
state->readptrcount)", errorType=errorType@entry=0x901ca8
"FailedAssertion", fileName=fileName@entry=0xaddb9b "tuplestore.c",
lineNumber=lineNumber@entry=478) at assert.c:54
#3  0x00000000008ef366 in tuplestore_select_read_pointer
(state=<optimized out>, ptr=<optimized out>) at tuplestore.c:478
#4  0x000000000066dafe in update_frameheadpos
(winstate=winstate@entry=0x1708ab0) at nodeWindowAgg.c:1579
#5  0x000000000066f018 in eval_windowaggregates
(winstate=winstate@entry=0x1708ab0) at nodeWindowAgg.c:735
#6  0x000000000066fb2c in ExecWindowAgg (pstate=0x1708ab0) at
nodeWindowAgg.c:2196
#7  0x0000000000643edf in ExecProcNodeFirst (node=0x1708ab0) at
execProcnode.c:445
#8  0x000000000063cc54 in ExecProcNode (node=0x1708ab0) at
../../../src/include/executor/executor.h:237
#9  ExecutePlan (estate=estate@entry=0x1708898, planstate=0x1708ab0,
use_parallel_mode=false, operation=operation@entry=CMD_SELECT,
sendTuples=sendTuples@entry=true, numberTuples=numberTuples@entry=0,
direction=ForwardScanDirection, dest=0x1707ca8, execute_once=true) at
execMain.c:1726
#10 0x000000000063d7c3 in standard_ExecutorRun (queryDesc=0x1664e98,
direction=ForwardScanDirection, count=0, execute_once=<optimized out>)
at execMain.c:363
#11 0x000000000063d84b in ExecutorRun
(queryDesc=queryDesc@entry=0x1664e98,
direction=direction@entry=ForwardScanDirection, count=count@entry=0,
execute_once=<optimized out>) at execMain.c:306
#12 0x00000000007a37b8 in PortalRunSelect
(portal=portal@entry=0x15d2a08, forward=forward@entry=true, count=0,
count@entry=9223372036854775807, dest=dest@entry=0x1707ca8) at
pquery.c:932
#13 0x00000000007a4e83 in PortalRun (portal=portal@entry=0x15d2a08,
count=count@entry=9223372036854775807,
isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true,
dest=dest@entry=0x1707ca8, altdest=altdest@entry=0x1707ca8,
completionTag=0x7ffc3a501f90 "") at pquery.c:773
#14 0x00000000007a13a8 in exec_simple_query
(query_string=query_string@entry=0x156e668 "select f1, sum(f1) over
(partition by f1 order by f2\n", ' ' <repeats 25 times>, "range
between 1 preceding and 1 following)\nfrom t1 where f1 = f2;") at
postgres.c:1122
#15 0x00000000007a30f5 in PostgresMain (argc=<optimized out>,
argv=argv@entry=0x15990a8, dbname=0x1598f10 "ddolgov",
username=<optimized out>) at postgres.c:4153
#16 0x0000000000720490 in BackendRun (port=port@entry=0x158f890) at
postmaster.c:4361
#17 0x000000000072307d in BackendStartup (port=port@entry=0x158f890)
at postmaster.c:4033
#18 0x000000000072335d in ServerLoop () at postmaster.c:1706
#19 0x00000000007245e2 in PostmasterMain (argc=argc@entry=3,
argv=argv@entry=0x15690f0) at postmaster.c:1379
#20 0x0000000000689dbb in main (argc=3, argv=0x15690f0) at main.c:228

I'll investigate it in the more details soon.


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) ='YYYY-MM-DD' does not push to remote.
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: BUG #15285: Query used index over field with ICU collation insome cases wrongly return 0 rows