Re: min_safe_lsn column in pg_replication_slots view
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgbf@twiska.com, Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
masao.fujii@oss.nttdata.com, pgsql-hackers@lists.postgresql.org
Date: 2020-07-09T01:03:55Z
Lists: 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
Commits
-
Fix uninitialized value in segno calculation
- b5b4c0fef9fb 14.0 landed
- 794e8e32bb5a 13.0 landed
-
Morph pg_replication_slots.min_safe_lsn to safe_wal_size
- c54b5891f415 13.0 landed
- a8aaa0c786b3 14.0 landed