Re: Two small patches for the isolationtester lexer

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

In response to

Responses

Browse pgsql-hackers by date

  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