Re: Frontend error logging style

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Frontend error logging style
Date: 2022-04-08 20:26:49
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> One other loose end is bothering me: I stuck with logging.h's
> original choice to put "if (likely())" or "if (unlikely())"
> conditionals into the macros, but I rather suspect that that's
> just a waste. I think we should put a centralized level check
> into logging.c, and get rid of at least the "if (likely())"
> checks, because those are going to succeed approximately 100.0%
> of the time. Maybe there's an argument for keeping the unlikely()
> ones.

Concretely, something like the attached. As a simple check,
I looked at the compiled size of pg_dump. It went from

text data bss dec hex filename
380298 4008 1384 385690 5e29a /home/postgres/testversion/bin/pg_dump


text data bss dec hex filename
374954 4008 1384 380346 5cdba src/bin/pg_dump/pg_dump

for a savings of about 5K or 1.5%. Not a huge amount, but
not nothing either, especially considering that the existing
coding isn't buying us anything.

regards, tom lane

Attachment Content-Type Size
remove-likely-from-logging-macros.patch text/x-diff 3.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-04-08 20:28:58 Re: Lowering the ever-growing heap->pd_lower
Previous Message Andrei Zubkov 2022-04-08 20:25:18 Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements