From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: pg_read_file() with virtual files returns empty string |
Date: | 2020-07-02 18:05:54 |
Message-ID: | e7f9326a-5374-8837-2539-f44a0a304093@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/1/20 6:22 PM, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> The only downside is that the max filesize is reduced to (MaxAllocSize -
>> MIN_READ_SIZE - 1) compared to MaxAllocSize with the old method.
>
> Hm, I was expecting that the last successful iteration of
> enlargeStringInfo would increase the buffer size to MaxAllocSize,
> so that we'd really only be losing one byte (which we can't avoid
> if we use stringinfo). But you're right that it's most likely moot
> since later manipulations of such a result would risk hitting overflows.
>
> I marked the CF entry as RFC.
Sorry to open this can of worms again, but I couldn't get my head past the fact
that reading the entire file would have a different size limit than reading the
exact number of bytes in the file.
So, inspired by what you did (and StringInfo itself) I came up with the
attached. This version performs equivalently to your patch (and HEAD), and
allows files up to and including (MaxAllocSize - VARHDRSZ) -- i.e. exactly the
same as the specified-length case and legacy behavior for the full file read.
But if you object I will just go with your version barring any other opinions.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
Attachment | Content-Type | Size |
---|---|---|
read-virtual-files.05.patch | text/x-patch | 4.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-07-02 18:07:03 | Re: Use of "long" in incremental sort code |
Previous Message | James Coleman | 2020-07-02 17:53:32 | Re: Use of "long" in incremental sort code |