Re: min_safe_lsn column in pg_replication_slots view

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: min_safe_lsn column in pg_replication_slots view
Дата
Msg-id 1773306.1594256635@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: min_safe_lsn column in pg_replication_slots view  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: min_safe_lsn column in pg_replication_slots view  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-Jul-08, Tom Lane wrote:
>> We did not.  If it's a compiler bug, and one as phase-of-the-moon-
>> dependent as this seems to be, I'd have zero confidence that any
>> specific source code change would fix it (barring someone confidently
>> explaining exactly what the compiler bug is, anyway).  The best we
>> can do for now is hope that backing off the -O level avoids the bug.

> An easy workaround might be to add -O0 for that platform in that
> directory's Makefile.

"Back off the -O level in one directory" seems about as misguided as
"back off the -O level in one branch", if you ask me.  There's no
reason to suppose that the problem won't bite us somewhere else next
week.

The previous sparc32 bug that we'd made some effort to run to ground
is described here:
https://www.postgresql.org/message-id/15142.1498165769@sss.pgh.pa.us
We really don't know what aspects of the source code trigger that.
I'm slightly suspicious that we might be seeing the same bug in the
sparc64 builds, but it's just a guess.

            regards, tom lane



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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Reigning in ExecParallelHashRepartitionFirst
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: jsonpath versus NaN