Re: min_safe_lsn column in pg_replication_slots view - Mailing list pgsql-hackers

From Tom Lane
Subject Re: min_safe_lsn column in pg_replication_slots view
Date
Msg-id 1773306.1594256635@sss.pgh.pa.us
Whole thread Raw
In response to Re: min_safe_lsn column in pg_replication_slots view  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: min_safe_lsn column in pg_replication_slots view  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Reigning in ExecParallelHashRepartitionFirst
Next
From: Alexander Korotkov
Date:
Subject: Re: jsonpath versus NaN