| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | alexey(dot)kuntsevich(at)gmail(dot)com |
| Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14218: pg_logical_slot_get_changes causes segmentation fault |
| Date: | 2016-06-29 07:19:01 |
| Message-ID: | CAM3SWZRryQo_wC=uQiH+oUh=2w_qezZNTNtvCCTbD7mPb73txQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jun 29, 2016 at 12:10 AM, <alexey(dot)kuntsevich(at)gmail(dot)com> wrote:
> We enabled logical replication on our postgresql cluster, created a new
> replication slot with vanilla test_decoding decoder and ran an app that
> polls 10000 rows from this slot once per second. It ran fine for a day,
> survived several bulk uploads of ~1mln rows until we did bulk upload of
> ~8mln rows at once. During the upload our postgresql instance disconnected
> all clients and reported that it is in recovery. Core dump was created and
> when we checked the logs we saw
Can you show a backtrace from the coredump?
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexey Kuntsevich | 2016-06-29 11:55:03 | Re: BUG #14218: pg_logical_slot_get_changes causes segmentation fault |
| Previous Message | alexey.kuntsevich | 2016-06-29 07:10:22 | BUG #14218: pg_logical_slot_get_changes causes segmentation fault |