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 00:35:49
Message-ID: 1772079.1594254949@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've previously noted what seem to be compiler optimization bugs on
>> both sparc32 and sparc64; the latest thread about that is
>> https://www.postgresql.org/message-id/flat/f28f842d-e82b-4e30-a81a-2a1f9fa4a8e1%40www.fastmail.com
>> This is looking uncomfortably like the same thing.

> Ouch. So 12 builds with -O0 but 13 does not?

Unless Tom's changed the animal's config since that thread, yes.

> Did we do something to
> sequence.c to work around this problem? I cannot find anything.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tsunakawa.takay@fujitsu.com 2020-07-09 00:49:21 RE: Postgres is not able to handle more than 4k tables!?
Previous Message Alvaro Herrera 2020-07-08 23:35:26 Re: min_safe_lsn column in pg_replication_slots view