Re: pg_logical_slot_peek_changes crashes postgres when called from inside pl/pgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
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-05 23:42:30
Message-ID: 4563.1507246950@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-10-05 17:43:39 -0400, Tom Lane wrote:
>> Nah, I take that back. The AbortCurrentTransaction call looks funny
>> (and is sadly underdocumented) but it's not invalid to call it and
>> then call RollbackAndReleaseCurrentSubTransaction.

> It's not perfectly documented, but there's some:

What I'm on about is that I think the AbortCurrentTransaction call needs a
comment along the lines of

* Roll back the current (sub)transaction. In the using_subtxn
* case, we could leave it to RollbackAndReleaseCurrentSubTransaction
* to do this, but we do it separately anyway because XYZ.

It's the fact that XYZ isn't very obvious that makes this comment
necessary. I'm guessing it's because ReorderBufferExecuteInvalidations
either doesn't work or is less efficient if inside a still-valid
transaction, but the fact that I need to guess is the problem.

>> I'm not sure about a good way to fix #2 without re-introducing the memory
>> leaks that call was added to fix (cf 7ec1c5a86).

> I think I don't fully understand what 7ec1c5a86 is trying to
> achieve.

I dug around in the archives and found

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2017-10-06 00:59:15 Re: pg_logical_slot_peek_changes crashes postgres when called from inside pl/pgsql
Previous Message Andres Freund 2017-10-05 23:16:11 Re: BUG #14843: CREATE TABLE churns through all memory, crashes db