|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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.
|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|