Re: pg_read_file() with virtual files returns empty string

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: pg_read_file() with virtual files returns empty string
Date: 2020-07-02 19:36:34
Message-ID: 863690.1593718594@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)com> writes:
> On 7/1/20 6:22 PM, Tom Lane wrote:
>> 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.

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

Are you sure there actually is any such limit in the other code,
after accounting for the way that stringinfo.c will enlarge its
buffer? That is, I believe that the limit is MaxAllocSize minus
five bytes, not something less.

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

I find this way overcomplicated for what it accomplishes. In the
real world there's not much difference between MaxAllocSize minus
five and MaxAllocSize minus four.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-02 19:39:42 Re: Use of "long" in incremental sort code
Previous Message Tom Lane 2020-07-02 19:29:11 Re: Sync vs Flush