Andrew Gierth writes:
> What's happening in the original case is this: the SRF call protocol
> says that it's the executor's responsibility to free rsi.setDesc if it's
> not refcounted, under the assumption that in such a case it's in
> per-query memory (and not in either a shorter-lived or longer
On Wed, Jul 11, 2018 at 11:38:46AM +0100, Andrew Gierth wrote:
> My first approach - assuming that update_cached_tupdesc has good reason
> to make a copy, which I'm not convinced is the case - would be to simply
> make a per-query-context copy of the tupdesc to assign to rsi.setDesc in
> order to c
> "Michael" == Michael Paquier writes:
>> I don't think that your solution is correct. From my read of
>> 37a795a6, the tuple descriptor is moved from the query-lifespan
>> memory context (ecxt_per_query_memory) to a function-level context,
>> which could cause the descriptor to become bu
> On Wed, 11 Jul 2018 at 08:27, Michael Paquier wrote:
>
> On Tue, Jul 10, 2018 at 10:39:28PM +0200, Dmitry Dolgov wrote:
> > I've found out that currently in some situations jsonb_to_recordset can
> > lead to
> > a crash. Minimal example that I've managed to create looks like this:
>
> It would
On Wed, Jul 11, 2018 at 03:27:13PM +0900, Michael Paquier wrote:
> I don't think that your solution is correct. From my read of 37a795a6,
> the tuple descriptor is moved from the query-lifespan memory context
> (ecxt_per_query_memory) to a function-level context, which could cause
> the descriptor
On Tue, Jul 10, 2018 at 10:39:28PM +0200, Dmitry Dolgov wrote:
> I've found out that currently in some situations jsonb_to_recordset can lead
> to
> a crash. Minimal example that I've managed to create looks like this:
It would be better not to send the same email across multiple mailing
lists.
