Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
| От | Tom Lane |
|---|---|
| Тема | Re: "invalid memory alloc request size |
| Дата | |
| Msg-id | 21410.1102087060@sss.pgh.pa.us обсуждение |
| Ответ на |
"invalid memory alloc request size |
| Ответы |
Re: "invalid memory alloc request size |
| Список | pgsql-bugs |
Frank van Vugt <ftm.van.vugt@foxi.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
В списке pgsql-bugs по дате отправления: