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

From: Lukas Fittl <lukas(at)fittl(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:45:12
Message-ID: CAP53PkwDGqaafZ_qtqu99yqOiXYT05fXE4Gzcm+=0GX-yBu7MA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 27, 2017 at 8:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Pushed with minor adjustments.
>

Excellent - thanks for your review and all the discussion here!

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

Makes sense, guess I was overthinking this one.

Best,
Lukas

--
Lukas Fittl

Skype: lfittl
Phone: +1 415 321 0630 <(415)%20321-0630>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stas Kelvich 2017-03-28 00:50:28 Re: logical decoding of two-phase transactions
Previous Message Michael Paquier 2017-03-28 00:37:53 Re: Potential data loss of 2PC files