From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgbf(at)twiska(dot)com, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: min_safe_lsn column in pg_replication_slots view |
Date: | 2020-07-09 01:03:55 |
Message-ID: | 1773306.1594256635@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2020-07-09 01:04:19 | Re: jsonpath versus NaN |
Previous Message | Melanie Plageman | 2020-07-09 00:57:30 | Re: Reigning in ExecParallelHashRepartitionFirst |