Re: [PATCH] Use correct types and limits for PL/Perl SPI query results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Use correct types and limits for PL/Perl SPI query results
Date: 2016-03-14 18:28:43
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I thought about using UV where feasible, but it was not clear to me
>> whether unsigned numbers behave semantically differently from signed ones
>> in Perl. If they do, the change you suggest would create a small semantic
>> change in the behavior of code using spi_exec_query. I'm not sure it's
>> worth taking any risk of that, considering we already discourage people
>> from using spi_exec_query for large results.

> IVs and UVs are semantically equivalent, and Perl will automatically
> convert between them (and NVs) as necessary, i.e. when crossing

OK, thanks for the authoritative statement.

>> I don't much like having such hard-wired knowledge about Perl versions
>> in our code. Is there a way to identify this change other than
>> #if PERL_BCDVERSION >= 0x5019004 ?

> There isn't, unfortunately.

Sigh ... it was worth asking anyway.

>>> 3) To be able to actually return such result sets from sp_exec_query(),
>>> I had to change the repalloc() in spi_printtup() to repalloc_huge().

>> Hmm, good point. I wonder if there are any hazards to doing that.

> One hazard would be that people not heeding the warning in
> spi_exec_query will get a visit from the OOM killer (or death by swap)
> instead of a friendly "invalid memory alloc request size".

Yeah. But there are plenty of other ways to drive a backend into swap
hell, and the whole point of this change is to eliminate arbitrary
boundaries on query result size. So let's do it.

Thanks for the patch and discussion!

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-03-14 18:30:05 Re: Speed up Clog Access by increasing CLOG buffers
Previous Message Tom Lane 2016-03-14 18:24:21 Re: WIP: Upper planner pathification