Re: Coding in WalSndWaitForWal

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Coding in WalSndWaitForWal
Date: 2020-01-09 19:29:36
Message-ID: 20200109192936.GA5226@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-Nov-12, Andres Freund wrote:

> We still have the curious
> proc_exit(0);
> abort(); /* keep the compiler quiet */
>
> pattern in WalSndShutdown() - wouldn't the right approach to instead
> proc_exit() with pg_attribute_noreturn()?

proc_exit() is already marked noreturn ... and has been marked as such
since commit eeece9e60984 (2012), which is the same that added abort()
after some proc_exit calls as well as other routines that were already
marked noreturn, such as WalSenderMain(). However, back then we were
using the GCC-specific notation of __attribute__((noreturn)), so perhaps
the reason we kept the abort() (and a few breaks, etc) after proc_exit()
was to satisfy compilers other than GCC.

In modern times, we define pg_attribute_noreturn() like this:

/* GCC, Sunpro and XLC support aligned, packed and noreturn */
#if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_noreturn() __attribute__((noreturn))
#define HAVE_PG_ATTRIBUTE_NORETURN 1
#else
#define pg_attribute_noreturn()
#endif

I suppose this will cause warnings in compilers other than those, but
I'm not sure if we care. What about MSVC for example?

With the attached patch, everything compiles cleanly in my setup, no
warnings, but then it's GCC.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
procexit.patch text/x-diff 1.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-09 19:48:40 Re: Removing pg_pltemplate and creating "trustable" extensions
Previous Message Tom Lane 2020-01-09 19:24:06 Re: our checks for read-only queries are not great