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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
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 15:17:40
Message-ID: 21410.1102087060@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> writes:
> Meanwhile, one of the application developers here bumped into a way to
> reproduce what looks like the same memory alloc problem (exactly the same
> point in exactly the same trigger) using our application software
> only,

Oh good. Can you construct a self-contained test case then?

> Here are both the query-set and the corresponding backtrace.

The query set's not very interesting without a database to try it
against :-(

> I then got a firm set of results, all of which were looking like this:

> Hardware access (read/write) watchpoint 1: SerializableSnapshotData.xcnt
> Value = 1
> Hardware access (read/write) watchpoint 2: LatestSnapshotData.xcnt
> Value = 1

> All were located at sinval.c:888

This is the expected case. The failure in CopySnapshot has got to
indicate that somebody set one or the other field to some bizarrely
large value, though. I take it you didn't run the watchpointed backend
far enough to get the memory-alloc error?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Frank van Vugt 2004-12-03 15:26:08 Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running
Previous Message Magnus Hagander 2004-12-03 09:17:31 Re: Installation fails for postgresql-8.0.0-beta4 on Windo