Re: segmentation fault in execTuples.c#ExecStoreVirtualTuple

On 6. Januar 2015 at 07:20:21, Michael Paquier (michael.paquier@gmail.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