Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running - Mailing list pgsql-bugs

From Frank van Vugt
Subject Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
Date
Msg-id 200412032314.54371.ftm.van.vugt@foxi.nl
Whole thread Raw
In response to Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
> [ scratches head ... ]  AFAICS, the CopySnapshot that gets the error
> must be trying to copy one or the other of those snapshots.  Maybe you
> should look at the address passed to CopySnapshot and see what it's
> really pointing at, and where it came from.

Ok, stepping through the transaction didn't reveal any change in the
CopySnapshot address, except for the last one when the error occurs, which is
when the deferred trigger is executing an update statement.


I guess the only thing left for me is to try and create a script that will
reproduce the problem.... ;(


Please allow me to describe the sequence of events of the one thing that comes
to mind when I take another good look at the functions/triggers and try to
think about what could be causing this:

- db
    - a deferred trigger is defined on insert/update/delete of
        purchaseorder_line (pol)
    - this trigger is meant to update the corresponding purchaseorder(s)


- begin transaction

- select purchaseorder_line (pol) X for update
    (here it is determined whether or not to spawn the line)

- call function spawn_pol() on pol X
    (inside this function marked as volatile)
    - select pol X for update
        (in this case for the second time, it's called from other places too)
    - insert new pol Y
    - update old pol X
        (with regards to the spawned amount)

- update pol Y
    (with regards to a number of other fields)

- commit transaction
    - this will fire the earlier deferred trigger on pol
        - update purchaseorder (po) to which pols X and Y belong, using aggregates
        (it is this update statement where the error occurs)


The only thing I can think of is that the handling of pol X and creation of
pol Y from within spawn_pol() is somehow messing things up, but......

If this doesn't ring any alarm bells, then I'll start working on a script
first thing next Monday.





--
Best,




Frank.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: utf-8 flag always off in plperl function arguments
Next
From: Tom Lane
Date:
Subject: Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running