LE DISABLE TRIGGER), the UPDATE
crashed the server.
What else could I try?
Regards,
Ondřej Bouda
Dne 6.11.2018 v 19:52 Alvaro Herrera napsal(a):
On 2018-Nov-06, Ondřej Bouda wrote:
So we dumped and restored all our databases. After that, the crash on DELETE
never occurred (before, it was sever
ON public.schedulecard USING gist
(scheduletemplate_id, (period_day::integer % 7), timerange)
TABLESPACE pg_default;
When I drop it, the UPDATE statement gets executed without any problems.
When I create the index again, the same UPDATE crashes the server.
Regards,
Ondřej Bouda
able =
__func__ = "PostmasterMain"
#18 0x7f6a6b679616 in main (argc=5, argv=0x7f6a6d3af1f0) at
/build/postgresql-11-oDwOcQ/postgresql-11-11.0/build/../src/backend/main/main.c:228
No locals.
--
Regards,
Ondřej Bouda
assume you've got btree_gist installed?
Yes, version 1.5.
Regards,
Ondřej Bouda
ybe we will just drop the index until the bug gets fixed - better slow
queries than crashing servers...
Thanks,
Ondřej Bouda
upcoming version?
Regards,
Ondřej Bouda
[New LWP 8307]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: 11/main: usr mydb 127.0.0.1(56829)
UPDATE '.
Pro
SELECT min(u) FROM unnest(ARRAY[1,2,3]) u
or just define a separate least_array() / greatest_array() variant.
Regards,
Ondřej Bouda
tely (i.e., all rows
involved) and only then picks some of them to the inner table.
Regards,
Ondřej Bouda
