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 |
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 |