Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION

From: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, chris(dot)tessels(at)inergy(dot)nl, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION
Date: 2016-02-26 08:34:05
Message-ID: CACACo5RhQrLh9owexYsn8BE7nEroaqV+z=rKeCa1Cg_rimv-oA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Feb 25, 2016 at 6:06 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2016-02-25 09:02:07 +0100, Shulgin, Oleksandr wrote:
> > On Wed, Feb 24, 2016 at 10:52 PM, Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> >
> > Hm... this is against my understanding of what a compiler could (or
> > should) do. Do you have a documentation reference or other evidence?
>
> Which part does not conform to your expectations? Moving stores/loads
> around from where they're apparently happening in the C program?
>

> Repeatedly reading from memory instead of storing something on the
> stack?
>

This one. But now that I think about it, this can buy you a free register,
so yeah it can be an optimization in some contexts.

How does compiler know this is not multi-threaded program? Only because we
don't specify any -pthread flags (assuming gcc)? Or it doesn't know/care
at all and we have to specifically turn off thread-unsafe optimizations?

--
Alex

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Chris Tessels 2016-02-26 09:51:52 Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION
Previous Message Dean Rasheed 2016-02-26 08:27:20 Re: BUG #13988: "plan should not reference subplan's variable" whilst using row level security