> Hmm, this one smells like c203d6cf81b4 -- haven't seen any fixes for
> that one. Can you share more details on this? I think the failing
> update is on table with oid=557732818, but I might be wrong.
That's exactly the table, public.schedulecard.
We issue an UPDATE changing some of its columns. E.g.,
UPDATE public.schedulecard SET ext_ident=null,
rotates=false,period_num=1,period_day=2 WHERE id=3817
lets the server crash. See the main log:
2018-11-06 17:29:40.031 CET [30202] LOG: server process (PID 29879) was
terminated by signal 11: Segmentation fault
2018-11-06 17:29:40.031 CET [30202] DETAIL: Failed process was running:
UPDATE public.schedulecard SET ext_ident=null,
rotates=false,period_num=1,period_day=2 WHERE id=3817;
select * from schedulecard where id = 3817
2018-11-06 17:29:40.031 CET [30202] LOG: terminating any other active
server processes
The query is reproducible - it always lets the server segfault. It
crashes on multiple rows on that table -- actually, I haven't found any
non-failing row yet.
I thought triggers should be suspected. However, even when all the three
triggers have been disabled (ALTER TABLE 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 several times a day). However, the crash on
UPDATE still occurs on specific rows. We are quite certain no ALTER TABLE
statement was executed on the table after the restore.
There are two AFTER INSERT OR UPDATE constraint triggers and one BEFORE
INSERT OR UPDATE trigger on the table, all of which are implemented in
plpgsql. Multiple physical servers, on separate databases with identical
schema, crash on the same type of UPDATE query (different just in concrete
values to be updated). The same code worked perfectly on 10.x.
See the attached backtrace below. Can we do something else to catch the bug?
Or can we hope for this bug to be already fixed and released in the upcoming
version?
Hmm, this one smells like c203d6cf81b4 -- haven't seen any fixes for
that one. Can you share more details on this? I think the failing
update is on table with oid=557732818, but I might be wrong.
