On 2018-07-25 18:59:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-07-25 18:11:13 -0400, Alvaro Herrera wrote:
> >> But what would be the advantage of avoiding the context release inside
> >> FreeExecutorState? It seems pretty appropriate to me to do it there.
> >> You could argue
Andres Freund writes:
> On 2018-07-25 18:11:13 -0400, Alvaro Herrera wrote:
>> But what would be the advantage of avoiding the context release inside
>> FreeExecutorState? It seems pretty appropriate to me to do it there.
>> You could argue that the JIT context is definitely part of the estate
>>
On 2018-Jul-25, Andres Freund wrote:
> On 2018-07-25 18:11:13 -0400, Alvaro Herrera wrote:
> > On 2018-Jul-25, Andres Freund wrote:
> > But what would be the advantage of avoiding the context release inside
> > FreeExecutorState? It seems pretty appropriate to me to do it there.
> > You could ar
On 2018-07-25 18:11:13 -0400, Alvaro Herrera wrote:
> On 2018-Jul-25, Andres Freund wrote:
>
> > The fix is easy, releasing the JIT context should just happen in
> > FreeExecutorState(). Only thing is that that function has the following
> > comment in the header:
> > * Note: this is not responsi
On 2018-Jul-25, Andres Freund wrote:
> The fix is easy, releasing the JIT context should just happen in
> FreeExecutorState(). Only thing is that that function has the following
> comment in the header:
> * Note: this is not responsible for releasing non-memory resources,
> * such as open relati
Hi,
On 2018-07-25 08:41:29 -0700, Andres Freund wrote:
> Oh, interesting. It only crashes when compiling LLVM without LLVM's
> asserts enabled, even when using exactly the same LLVM checkout for both
> builds. No idea what that's about, yet.
Oh, well, this took me longer than it should have. The
On 2018-07-25 14:59:20 +0200, Dmitry Dolgov wrote:
> > On Wed, 25 Jul 2018 at 07:49, Michael Paquier wrote:
> >
> > On Tue, Jul 24, 2018 at 07:49:56PM -0700, Andres Freund wrote:
> > > FWIW, this doesn't crash for me, using a trunk checkout for LLVM. I'll
> > > try older ones, as soon as they fini
> On Wed, 25 Jul 2018 at 07:49, Michael Paquier wrote:
>
> On Tue, Jul 24, 2018 at 07:49:56PM -0700, Andres Freund wrote:
> > FWIW, this doesn't crash for me, using a trunk checkout for LLVM. I'll
> > try older ones, as soon as they finish rebuilding. But perhaps you could
> > re-verify that this
On Tue, Jul 24, 2018 at 07:49:56PM -0700, Andres Freund wrote:
> FWIW, this doesn't crash for me, using a trunk checkout for LLVM. I'll
> try older ones, as soon as they finish rebuilding. But perhaps you could
> re-verify that this still is an issue on recent PG checkouts? And which
> version of L
On 2018-07-10 09:19:58 +0900, Michael Paquier wrote:
> On Mon, Jul 09, 2018 at 04:04:11PM +0200, Dmitry Dolgov wrote:
> > # matview.sql
> > ...
> > =# REFRESH MATERIALIZED VIEW CONCURRENTLY mvtest_tm;
> > server closed the connection unexpectedly
> > This probably means the server terminated abnorm
On Mon, Jul 09, 2018 at 04:04:11PM +0200, Dmitry Dolgov wrote:
> # matview.sql
> ...
> =# REFRESH MATERIALIZED VIEW CONCURRENTLY mvtest_tm;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection t
Hi,
I've found out an interesting problem that you can reproduce by running
installcheck against a database with enabled llvm jit (with and without the
patch I've sent in [1]):
# postgresql.conf
jit = on
jit_above_cost = 0
jit_optimize_above_cost = 0
jit_inline_above_cost = 0
# matview.sql
...
=
12 matches
Mail list logo
