Re: log bind parameter values on error

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alexey Bashtanov <bashtanov(at)imap(dot)cc>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: log bind parameter values on error
Date: 2019-12-03 21:17:39
Message-ID: 20191203211739.GA12872@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2019-Dec-03, Alvaro Herrera wrote:

> Now, I have to say that this doesn't make me terribly happy, because I
> would like the additional ability to limit the printed values to N
> bytes. This means the new function would have to have an additional
> argument to indicate the maximum length (pass 0 to print all args
> whole) ... and the logic then because more involved because we need
> logic to stop printing early.

So after actually writing this, it seems that it's better to have a
separate path for this; otherwise you need to scan the whole input
string (strchr or friends), which might be long. I tried to see how to
make strnlen() work for us, but I found no simple way to print the "..."
at the end. So this just runs once per char. I think that's okay,
since the intended usage is to print a few dozen bytes, like
ExecBuildSlotValueDescription does (64 bytes is what all its callers

Another point: this implementation is not strict about how many
input characters it prints. It counts up to maxlen *output* characters,
which means if it duplicates a ', that's one less input char printed.
(Given the usage of this function, this seems a feature rather than a
bug. The first implementation did the opposite, and on the whole it
seemed worse.)

If anyone can suggest a smarter implementation, I'm all ears.

(Maybe do strnlen(maxlen), then count strnlen(1) starting at that point
-- so if that returns >=1, print the "..."?)

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-12-03 21:22:17 Re: How to prohibit parallel scan through tableam?
Previous Message Masahiko Sawada 2019-12-03 20:32:41 Re: Using XLogFileNameP in critical section