Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

From: Dent John <denty(at)QQdd(dot)eu>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Roman Pekar <roma(dot)pekar(at)gmail(dot)com>
Subject: Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR
Date: 2020-01-19 22:30:33
Message-ID: 2C39C44A-11B1-47A9-AF0D-5E0DCFEC4F1B@QQdd.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 11 Jan 2020, at 12:04, Dent John <denty(at)QQdd(dot)eu> wrote:
>
>> On 10 Jan 2020, at 15:45, Daniel Verite <daniel(at)manitou-mail(dot)org> wrote:
>>
>> postgres=# select unnest('c'::refcursor);
>> server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the request.
>> The connection to the server was lost. Attempting reset: Failed.
>
> Okay. That’s pretty bad, isn’t it.

I’ve addressed the issue, which was due to me allocating the TupleDesc in the multi_call_memory_ctx, which seemed quite reasonable, but it actually needs to be in ecxt_per_query_memory. It seems tSRF-mode queries are much more sensitive to the misstep.

A v4 patch is attached, which also renames UNNEST(REFCURSOR) to ROWS_IN(REFCURSOR), adds a test case for use in tSRF mode, and makes some minor fixes to the support function.

I have not yet made steps towards documentation, nor yet rebased, so the Makefile chunk will probably still fail.

denty.

Attachment Content-Type Size
unnest-refcursor-v4.patch application/octet-stream 25.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2020-01-19 22:45:53 Re: longs where uint64s could be
Previous Message Tom Lane 2020-01-19 21:48:05 Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line