| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Ben Chobot <bench(at)silentmedia(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: pg_logical_slot_peek_changes crashes postgres when called from inside pl/pgsql |
| Date: | 2017-10-06 00:59:15 |
| Message-ID: | 20171006005915.lyivbm6fplmbmon2@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2017-10-05 19:42:30 -0400, Tom Lane wrote:
> I dug around in the archives and found
Ah thanks.
> https://www.postgresql.org/message-id/26365.1162532453%40sss.pgh.pa.us
>
> The function shown there doesn't appear to leak any memory at all in HEAD,
> but if you dike out the memory context reset in question, it leaks like
> crazy. I didn't try to reconfirm my old estimate of 16KB per iteration,
> but it seemed to be in that ballpark still.
Just ran this, got out-of-memory error, and then another out-of-memory
error, ... I wonder if we should exclude out_of_memory from OTHERS,
like we do QUERY_CANCELED and ASSERT_FAILURE.
(looking)
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-10-06 01:00:11 | Re: BUG #14843: CREATE TABLE churns through all memory, crashes db |
| Previous Message | Tom Lane | 2017-10-05 23:42:30 | Re: pg_logical_slot_peek_changes crashes postgres when called from inside pl/pgsql |