Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running

From: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running
Date: 2004-12-03 22:14:54
Message-ID: 200412032314.54371.ftm.van.vugt@foxi.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2004-12-03 22:27:37 Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running
Previous Message Tom Lane 2004-12-03 20:37:41 Re: utf-8 flag always off in plperl function arguments