From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Missing errcode() in ereport
Date: Mon, 23 Mar 2020 17:57:28 -0400
Message-ID: <3780.1585000648@sss.pgh.pa.us> (raw)
In-Reply-To: <20200323214446.omszgudfu3etpieu@alap3.anarazel.de>
References: <32174.1584454158@sss.pgh.pa.us>
<20200319175902.vjib2tslosw65iyr@alap3.anarazel.de>
<5063.1584641224@sss.pgh.pa.us>
<20200319230446.lxjybufdcgwaqkhj@alap3.anarazel.de>
<5995.1584660775@sss.pgh.pa.us>
<20200320015908.ajxneh4jx6avqegv@alap3.anarazel.de>
<9966.1584671550@sss.pgh.pa.us>
<20200320045637.n3xo6gcmbqcg42tq@alap3.anarazel.de>
<15922.1584715221@sss.pgh.pa.us>
<31649.1584998689@sss.pgh.pa.us>
<20200323214446.omszgudfu3etpieu@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> I wondered before whether there's a way we could move the elevel check
> in errstart to the macro. For it to be a win we'd presumably have to
> have a "synthesized" log_level variable, basically
> min(log_min_messages, client_min_messages, ERROR).
> Probably not worth it.
Yeah, I don't really agree with that idea. The whole business of which
elevels will trigger output is fundamentally policy, not mechanism,
and you do not want policy decisions embedded into ABI so that there
are hundreds of copies of them. It's a loss for code size and a worse
loss if you ever want to change the behavior.
> On 2020-03-23 17:24:49 -0400, Tom Lane wrote:
>> One thing I'm not totally sure about is whether we can rely on
>> this change:
>>
>> -extern void errfinish(int dummy,...);
>> +extern void errfinish(void);
>>
>> being fully ABI-transparent. One would think that as long as errfinish
>> doesn't inspect its argument(s) it doesn't matter whether any are passed,
>> but maybe somewhere there's an architecture where the possible presence
>> of varargs arguments makes for a significant difference in the calling
>> convention? We could leave that change out of the v12 patch if we're
>> worried about it.
> I would vote for leaving that out of the v12 patch. I'm less worried
> about odd architectures, and more about sanitizers and/or compilers
> emitting "security enhanced" code checking signatures match etc
> ("control flow integrity").
Yeah, good point. Let's skinny the v12 patch down to just macro
and docs changes, then, not touching elog.c at all.
I made a commitfest entry for this just to see what the cfbot
thinks of it, but if there are not objections we should go ahead
and push in a day or so, IMO.
regards, tom lane
BTW, the CF app is showing me as the first author, even though
I definitely put you in first. Guess it doesn't care about
author ordering ... is that a bug to be fixed?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, amit.kapila16@gmail.com, michael@paquier.xyz, rjuju123@gmail.com, masahiko.sawada@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Missing errcode() in ereport
In-Reply-To: <3780.1585000648@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox