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 |
Date: | 2018-02-27 07:47:22 |
Message-ID: | 70FF0777-BD41-4A15-AA6E-162E25EBC8C8@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
cheers ./daniel
Attachment | Content-Type | Size |
---|---|---|
0001-Grow-isolation-spec-scanner-buffer-on-large-SQL-step.patch | application/octet-stream | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
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 |