From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>,
        Vik Fearing <vik@postgresfriends.org>,
 cary huang <hcary328@gmail.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Add support for AT LOCAL
In-reply-to: 
 <CA+hUKGLYaVJ7df+Uu=ctUunRcqUsGY55feVQa-1pzz1=PT=z3w@mail.gmail.com>
References: <e3b4c42d-739d-4375-9401-2f62ad59d326@postgresfriends.org>
 <ZSTUWON7DOfo-2ES@paquier.xyz>
 <a2bd6444-7fe4-44cd-8cb6-d7ac13f4d3e0@postgresfriends.org>
 <ZSjCZJrxGL0-wv-G@paquier.xyz>
 <65b620bd-4f05-4381-97c3-5ec9ac39d5b9@postgresfriends.org>
 <ZSjQj34RZBY_HY0c@paquier.xyz>
 <CA+hUKGK=DOC+hE-62FKfZy=Ybt5uLkrg3zCZD-jFykM-iPn8yw@mail.gmail.com>
 <2129576.1697407071@sss.pgh.pa.us>
 <CA+hUKGJE7rfnswHh021=vJmV3wAjmWfbb2BGp6CfeMk0rPyPLQ@mail.gmail.com>
 <CA+hUKGL04vme+yztreEFhGucv2d9ema+8_a+i43EUFdpYCPXfw@mail.gmail.com>
 <ZSyYqySa74x_RAH_@paquier.xyz>
 <CA+hUKGLYaVJ7df+Uu=ctUunRcqUsGY55feVQa-1pzz1=PT=z3w@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Mon, 16 Oct 2023 15:53:56 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2188263.1697425365.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 15 Oct 2023 23:02:45 -0400
Message-ID: <2188264.1697425365@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2188264.1697425365%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Oct 16, 2023 at 2:58=E2=80=AFPM Michael Paquier <michael@paquier=
.xyz> wrote:
>> Another theory would be one of these weird compiler optimization issue
>> from xlc?  In recent history, there was 8d2a01ae12cd.

> Yeah, there are more like that too.  xlc 12.1 is dead (like the OS
> version it shipped with).  New versions are available on cfarm if we
> care about this target.  But I am conscious of the cosmic law that if
> you blame the compiler too soon you can cause the bug to move into
> your code...

I'm having a hard time not believing that this is a compiler bug.
Looking back at 8d2a01ae12cd and its speculation that xlc is overly
liberal about reordering code around sequence points ... I wonder
if it'd help to do this calculation in a local variable, and only
assign the final value to result->time ?  But we have to reproduce
the problem first.

			regards, tom lane