Re: Coding in WalSndWaitForWal

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Coding in WalSndWaitForWal
Дата
Msg-id 20200109192936.GA5226@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Coding in WalSndWaitForWal  (Andres Freund <andres@anarazel.de>)
Ответы Re: Coding in WalSndWaitForWal  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: our checks for read-only queries are not great
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Removing pg_pltemplate and creating "trustable" extensions