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-11 12:04:05
Message-ID: 858F7EC2-4BEE-4871-96AE-AB3A8BA5B113@QQdd.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 10 Jan 2020, at 15:45, Daniel Verite <daniel(at)manitou-mail(dot)org> wrote:
>
> At a quick glance, I don't see it called in the select-list in any
> of the regression tests. […]

Yep. I didn’t test it because I figured it wasn’t particularly useful in that context. I’ll add some tests for that too once I get to the root of the problem.

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

It’s crashing when it’s checking that the returned tuple matches the declared return type in rsinfo->setDesc. Seems rsinfo->setDesc gets overwritten. So I think I have a memory management problem.

To be honest, I wasn’t fully sure I’d got a clear understanding of what is in what memory context, but things seemed to work so I figured it was close. Seems I was wrong. I need a bit of time to review. Leave it with me, but I guess it’ll take to next weekend before I get more time.

denty.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2020-01-11 12:21:15 Re: Avoid full GIN index scan when possible
Previous Message Artur Zakirov 2020-01-11 10:04:50 Re: Add pg_file_sync() to adminpack