search

postgrespro / vops

Other
166 stars 22 forks source link

server crash with select on fdw table #5

Closed legrandlegrand closed 6 years ago

legrandlegrand commented 6 years ago

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 ()

knizhnik commented 6 years ago

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).

knizhnik commented 6 years ago

Add compile time check preventing VOPS from been built for 32-bit version of Postgres