Re: log bind parameter values on error

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-09 21:00:49
Message-ID: 20191209210049.yvcmtqaqa4vznd6m@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-12-09 17:05:31 -0300, Alvaro Herrera wrote:
> * Thoughts from Andres, who was busily messing about with stringinfo.c
> on his patch series for programmatic out/read node functions?

I don't immediately see a need for mb functionality there. But to me it
seems pretty clear that we're going to need mb functionality in more
frontend programs over time. The only frontend part needing stringinfo
there is the metadata generation tool, and that doesn't care about
anything like this. The node functions themselves are obviously still
backend only.

I'm not even sure that it's worth caring over the binary size this way,
tbh. If somebody is actually concerned about that, they ought to use LTO
+ -Os, leading to unreferenced functions (and even unreferenced *parts*
of functions) getting completely thrown out.

I'd also assume that size number you cited earlier contains debug
information etc? Because after stripping / without debug information, I
get like 110k/97k for assert/optimize builds of waldump from master?
130k/113k for v18. And 110k/97k for v19.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-09 21:05:58 Re: log bind parameter values on error
Previous Message Jeff Janes 2019-12-09 20:51:39 Re: Index corruption / planner issue with one table in my pg 11.6 instance