Re: [HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

2015-07-18 Thread Michael Paquier 
On Fri, Jul 17, 2015 at 11:37 PM, Tom Lane  wrote:
> Geoff Winkless  writes:
>> While doing some testing of 9.5a one of my colleagues (not on list) found a
>> reproducible server segfault.
>
> Hm, looks like commit 1345cc67bbb014209714af32b5681b1e11eaf964 is to
> blame: memory management for the plpgsql cast cache needs to be more
> complicated than I realized :-(.

And this issue is already fixed by 0fc94a5b.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

2015-07-17 Thread Tom Lane 
Geoff Winkless  writes:
> While doing some testing of 9.5a one of my colleagues (not on list) found a
> reproducible server segfault.

Hm, looks like commit 1345cc67bbb014209714af32b5681b1e11eaf964 is to
blame: memory management for the plpgsql cast cache needs to be more
complicated than I realized :-(.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

2015-07-17 Thread Geoff Winkless 
On 17 July 2015 at 13:49, Michael Paquier  wrote:

> On Fri, Jul 17, 2015 at 7:52 PM, Geoff Winkless 
> wrote:
> > While doing some testing of 9.5a one of my colleagues (not on list)
> found a
> > reproducible server segfault.
> > [...]
> > Hope someone can get something useful from the above. Any questions,
> please
> > ask.
>
> I am adding it to the list of Open Items for 9.5. I'll look into that
> in the next couple of days (Tuesday at worst).
>

​
Superb, thanks :)

​Geoff​

Re: [HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

2015-07-17 Thread Michael Paquier 
On Fri, Jul 17, 2015 at 7:52 PM, Geoff Winkless  wrote:
> While doing some testing of 9.5a one of my colleagues (not on list) found a
> reproducible server segfault.
> [...]
> Hope someone can get something useful from the above. Any questions, please
> ask.

A test case is more than enough to look at this issue and guess what
is happening, thanks! The issue can be reproduced on REL9_5_STABLE and
master, and by looking at the stack trace it seems that the problem is
caused by an attempt to delete a memory context that has already been
free'd.

* thread #1: tid = 0x, 0x000109f30dee
postgres`MemoryContextDelete(context=0x7f7f7f7f7f7f7f7f) + 30 at
mcxt.c:206, stop reason = signal SIGSTOP
frame #0: 0x000109f30dee
postgres`MemoryContextDelete(context=0x7f7f7f7f7f7f7f7f) + 30 at
mcxt.c:206
   203 void
   204 MemoryContextDelete(MemoryContext context)
   205 {
-> 206 AssertArg(MemoryContextIsValid(context));
   207 /* We had better not be deleting TopMemoryContext ... */
   208 Assert(context != TopMemoryContext);
   209 /* And not CurrentMemoryContext, either */
(lldb) bt
* thread #1: tid = 0x, 0x000109f30dee
postgres`MemoryContextDelete(context=0x7f7f7f7f7f7f7f7f) + 30 at
mcxt.c:206, stop reason = signal SIGSTOP
  * frame #0: 0x000109f30dee
postgres`MemoryContextDelete(context=0x7f7f7f7f7f7f7f7f) + 30 at
mcxt.c:206
frame #1: 0x000109b7e261
postgres`fmgr_sql(fcinfo=0x7f84c28d5870) + 433 at functions.c:1044

I am adding it to the list of Open Items for 9.5. I'll look into that
in the next couple of days (Tuesday at worst).
Regards,
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

2015-07-17 Thread Geoff Winkless 
Hi all

While doing some testing of 9.5a one of my colleagues (not on list) found a
reproducible server segfault.

We've broken it down to a minimal script to reproduce below.

Reproduced on both machines on which we've installed 9.5 so far (both built
from source since we don't have any RHEL7 machines in development):

RHEL5.3 (Linux 2.6.18-128.el5 i386), gcc version 4.6.4
CentOS 6.5 (Linux 2.6.32-431.el6.i686), gcc version 4.4.7-4

Script for psql:

 cut ===

CREATE OR REPLACE FUNCTION to_date(integer) RETURNS date LANGUAGE sql
IMMUTABLE AS $$

SELECT $1::text::date

$$;


DROP CAST IF EXISTS (integer AS date);

CREATE CAST (integer AS date) WITH FUNCTION to_date(integer) AS IMPLICIT;



CREATE OR REPLACE FUNCTION newcrash(INTEGER) returns DATE LANGUAGE plpgsql
AS $$ BEGIN

RETURN $1;

END$$;


SELECT newcrash(20150202);

SELECT newcrash(20150203);


 cut ===



It doesn't crash the first time, but does consistently crash the second.
Given that if I remove IMMUTABLE from the function definition it doesn't
fail, it implies that there's a problem with the mechanism used to cache
function results - although the fact that the second function call doesn't
have to be the same value does suggest it's a problem with the code that
*searches* that result cache, rather than the section that retrieves it.


I tried cutting out the implicit CAST altogether and doing

RETURN to_date($1);


but this doesn't fail, which implies also that it's something related to
the implicit cast.


If I DECLARE a local DATE variable and SELECT INTO that (rather than just
using RETURN $1), it crashes at that point too.

Hope someone can get something useful from the above. Any questions, please
ask.


Geoff