From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | piotrwlodarczyk89(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16184: Segmentation Fault during update |
Date: | 2020-01-02 15:33:15 |
Message-ID: | 17312.1577979195@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> Log:
> 2020-01-02 15:42:26 CET [12729]: [95-1] user=,db=,xid=0,state=00000 LOG:
> server process (PID 28879) was terminated by signal 11: Segmentation fault
> 2020-01-02 15:42:26 CET [12729]: [96-1] user=,db=,xid=0,state=00000 DETAIL:
> Failed process was running: UPDATE job_abstract a
> SET job_status = job_status
> WHERE (a.xmax :: TEXT :: BIGINT < (SELECT
> txid_snapshot_xmin(txid_current_snapshot()))) AND ((SELECT
Clearly a bug, but there's not much we can do with this amount of
information. If you can provide a stack trace, that'd be helpful.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
> Reproducting this bug is not easy and I don't know which conditions has to
> be met to replicate this bug. But during application is working and we made
> this update, segmentation fault occurs. But sometimes it works.
My gut instinct is that this might be a concurrent-update problem,
which would explain the lack of reproducibility. Try to get
multiple sessions to update the same table row(s) at the same time.
Also, we had some bugs of that ilk on 12.0, please make sure you
really are updated to 12.1.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2020-01-02 18:00:20 | Re: BUG #16183: PREPARED STATEMENT slowed down by jit |
Previous Message | PG Bug reporting form | 2020-01-02 15:16:45 | BUG #16184: Segmentation Fault during update |