|From:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Two small patches for the isolationtester lexer|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On 22 Feb 2018, at 05:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 21 Feb 2018, at 21:41, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I can't think of one; but I wonder if it's worth working a bit harder and
>>> removing the fixed limit altogether, probably by using a PQExpBuffer.
>>> If you've hit 1024 today, somebody will bump up against 2048 tomorrow.
>> The thought did cross my mind, but I opted for the simple hack first. I can
>> take a stab at using a PQExpBuffer to see where that leads.
> Another idea is just to teach addlitchar to realloc the buffer bigger
> when necessary.
I think this is the best approach for the task, the attached patch changes the
static allocation to instead realloc when required. Having an upper limit on
the allocation seemed like a good idea to me, but perhaps it’s overthinking and
complicating things for no good reason.
|Next Message||Daniel Gustafsson||2018-02-27 07:51:41||Re: Two small patches for the isolationtester lexer|
|Previous Message||Kato, Sho||2018-02-27 07:40:27||Scenario using pg_rewind|