Re: segmentation fault in execTuples.c#ExecStoreVirtualTuple

From: Manuel Kniep <manuel(at)adjust(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: segmentation fault in execTuples.c#ExecStoreVirtualTuple
Date: 2015-01-15 17:09:03
Message-ID: etPan.54b7f42f.66334873.109@Manuels-MacBook-Air-5.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6. Januar 2015 at 07:20:21, Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> On Tue, Jan 6, 2015 at 12:39 AM, Manuel Kniep wrote:
> > Hi,
> >
> > we are running postges 9.3.5 on gentoo linux kernel 3.16.5, compiled with gcc 4.8.3
> > Any ideas ?
>
> > #17 0x000000000062bb9d in SPI_execute_with_args (
> src=0x22b880bb0 "\n CREATE TEMPORARY TABLE
> > [...]
> > #33 0x00007f363555ab97 in plpgsql_exec_function (func=0xd888c8, fcinfo=0x7ffffaa89a60)
> at pl_exec.c:321
> > #34 0x00007f36355552be in plpgsql_call_handler (fcinfo=0x7ffffaa89a60) at pl_handler.c:129
> > [...]
> > #46 0x000000000072e4eb in exec_simple_query (
> > query_string=0xd633b0 "SELECT 'event' as item, '2014-12-30' as date, 'Backends::Backend9'
> as backend, '33' as bucket, * FROM materialize_events('2014-11-20', '2014-12-30')")
> at postgres.c:1048
> From the backtrace you are showing, you are creating a temporary table
> with CREATE TABLE AS within a plpgsql function. Could you provide a
> self-contained test case?
> --
> Michael

ok after lot’s of testing I could create a test case 
which can be found here https://gist.github.com/rapimo/3c8c1b35270e5854c524 
it’s written in ruby an depends on the gem activerecord pg and parallel 
the issue is basically the combination of writable CTE on a parent table and concurrent updates on the child table 

the test case create 3 child tables with 1e6 rows each  

CREATE TABLE test_data( 
  tracker_id  integer not null, 
  created_at timestamp, 
  processed boolean 
); 

and then runs the CTE command 

 CREATE TEMPORARY TABLE outtbl ON COMMIT DROP AS 
          WITH affected AS ( 
            UPDATE test_data t SET processed = true 
            WHERE tracker_id BETWEEN 200 AND 300 
            AND NOT processed 
            RETURNING 
              date(t.created_at) as date, tracker_id, created_at 
          ) 
          SELECT * FROM affected 

while this command is running 5 other concurrent updates do a 

UPDATE test_data SET tracker_id = 400 
      WHERE tracker_id = 200 
      and created_at = '2015-01-02 00:03:20' 
      and date(created_at) = '2015-01-02’ 

So my feeling is that the row exclusive lock is not taken properly on inherited tables. 
I tried the tastcase without inheritance and it did not segfault. 

If you don’t like ruby I might be able to rewrite the test case in bash. 

thanks 

Manuel 

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-01-15 17:14:39 Re: [PATCH] explain sortorder
Previous Message Andres Freund 2015-01-15 16:59:40 Re: s_lock.h default definitions are rather confused