Re: [PATCH] Use $ parameters as replacement characters for pg_stat_statements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lukas Fittl <lukas(at)fittl(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Use $ parameters as replacement characters for pg_stat_statements
Date: 2017-03-28 00:24:47
Message-ID: 2121.1490660687@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Lukas Fittl <lukas(at)fittl(dot)com> writes:
> On Sat, Mar 18, 2017 at 12:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So it turns out this discussion just reinvented the alternative that
>> Lukas had in his 0002 proposal. Are there any remaining objections
>> to proceeding with that approach?

> Thanks for reviewing - updated patch attached, comments below.

Pushed with minor adjustments.

The main non-cosmetic thing I did was to replace the floor(log10())
business with plain constant "10" as I suggested before. That's
what we do in other places --- see int4out for an example --- and
frankly I did not feel that a small space savings in a transient
string buffer was worth the intellectual effort to verify whether
that calculation was correct or not, never mind whatever runtime
cycles it would take. I don't believe the argument that it's safer
your way: if you had an off-by-one thinko in the calculation, or even
just roundoff error in the log10() call, it could result in an actual
reachable buffer overrun, because there's no safety margin.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Huong Dangminh 2017-03-28 00:25:37 Failed with build PostgreSQL in Windows ("--with-perl" option)
Previous Message Tsunakawa, Takayuki 2017-03-27 23:38:12 Re: Potential data loss of 2PC files