Re: min_safe_lsn column in pg_replication_slots view

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

In response to

Responses

Browse pgsql-hackers by date

  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