Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION
От | Shulgin, Oleksandr |
---|---|
Тема | Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION |
Дата | |
Msg-id | CACACo5RhQrLh9owexYsn8BE7nEroaqV+z=rKeCa1Cg_rimv-oA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13985: Segmentation fault on PREPARE TRANSACTION (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
On Thu, Feb 25, 2016 at 6:06 PM, Andres Freund <andres@anarazel.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@anarazel.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
В списке pgsql-bugs по дате отправления: