| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: PostgreSQL crashes with SIGSEGV |
| Date: | 2017-12-08 02:23:28 |
| Message-ID: | CAH2-WzkYZy633TUDQ6Uc-vq9uUj-57vFFKmZ5jGCskw47mJfLA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Thu, Dec 7, 2017 at 7:47 AM, Bernd Helmle <mailings(at)oopsware(dot)de> wrote:
> I've tested this so far against very current REL9_6_STABLE and
> REL9_5_STABLE and got them to crash with the same backtrace. The crash
> is dependent on the chosen plan, experiments with work_mem show that
> the crash seems to happen only if you get external sorts into the
> execution plan.
>
> REL10_STABLE seems not affected, as my extracted application query
> doesn't crash there.
Does "set replacement_sort_tuples = 0" change anything on
REL9_6_STABLE? If you only get a crash when there is very little
work_mem, then that might be a good avenue of investigation. Note that
my changes to external sorting started in REL9_6_STABLE, so they can't
be involved here.
Are you aware of commit 512f67c8d02cc558f9c269cc848b0f0f788c4fe1,
which fixed a bug affecting external sorts? Are you sure that you have
that fix on REL9_5_STABLE + REL9_6_STABLE?
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2017-12-08 02:54:51 | Re: PostgreSQL crashes with SIGSEGV |
| Previous Message | Michael Paquier | 2017-12-08 02:08:12 | Re: PostgreSQL crashes with SIGSEGV |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2017-12-08 02:29:22 | Re: Logical replication without a Primary Key |
| Previous Message | Michael Paquier | 2017-12-08 02:08:12 | Re: PostgreSQL crashes with SIGSEGV |