server crash with select on fdw table
legrandlegrand opened this issue · 2 comments
Hello Konstantin,
I shared thoses informations here, for other users that may hit the same problem.
SELECT
public.wiki_page.pagename,
sum(public.fdw_data.requests)
FROM
public.wiki_cat
INNER JOIN public.fdw_data
ON public.wiki_cat.cat_id = public.fdw_data.cat_id
INNER JOIN public.wiki_page
ON public.fdw_data.page_id = public.wiki_page.page_id
where
public.wiki_cat.category='en'
and public.wiki_page.pagename ='List_of_stock_market_crashes_and_bear_markets'
GROUP BY
public.wiki_page.pagename
ORDER BY
sum(public.fdw_data.requests) DESC
limit 10
;
sudo -u postgres gdb -q -c /var/lib/postgresql/10/main/core /usr/lib/postgresql/10/bin/postgres
Reading symbols from /usr/lib/postgresql/10/bin/postgres...(no debugging symbols found)...done.
[New LWP 4479]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: 10/main: postgres postgres 127.0.0.1(52050) SELECT '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:2673
2673 ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S: Aucun fichier ou dossier de ce type.
(gdb) bt
#0 __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:2673
#1 0xb6cbfb45 in __memcpy_ssse3 ()
at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:136
#2 0x080b851c in heap_fill_tuple ()
#3 0x080b92c4 in heap_form_tuple ()
#4 0xb4542eb5 in postgresIterateForeignScan (node=0xa2137f4) at vops_fdw.c:764
#5 0x082400aa in ?? ()
#6 0x08223bca in ExecScan ()
#7 0x0823ff76 in ?? ()
#8 0x082323a1 in ?? ()
#9 0x0823a902 in ?? ()
#10 0x0822921d in ?? ()
#11 0x0822b072 in ?? ()
#12 0x0823cbbd in ?? ()
#13 0x08234e5a in ?? ()
#14 0x0821e2a5 in standard_ExecutorRun ()
#15 0x0834188a in ?? ()
#16 0x08342c0f in PortalRun ()
#17 0x0833fcad in PostgresMain ()
#18 0x080b01e1 in ?? ()
#19 0x082d662b in PostmasterMain ()
#20 0x080b1427 in main ()
The problem is caused by using 32-bit version of Postgres. VOPS currently is tested only with 64-bit and I am not sure that I am going to support 32-bit version (VOPS is intended to be used for complex analytic and big data, running such queries at 32-bit system or 32-bit application seems to be strange idea nowdays).
Add compile time check preventing VOPS from been built for 32-bit version of Postgres