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