Re: Add support for AT LOCAL
От | Noah Misch |
---|---|
Тема | Re: Add support for AT LOCAL |
Дата | |
Msg-id | 20231016055051.3a@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: Add support for AT LOCAL (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Add support for AT LOCAL
|
Список | pgsql-hackers |
On Sun, Oct 15, 2023 at 09:58:04PM -0700, Noah Misch wrote: > On Sun, Oct 15, 2023 at 11:30:17PM -0400, Tom Lane wrote: > > Thomas Munro <thomas.munro@gmail.com> writes: > > > On Mon, Oct 16, 2023 at 4:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> 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. > > > > > If that can be shown I would vote for switching to /opt/IBM/xlc/16.1.0 > > > and not changing a single bit of PostgreSQL. > > > > If switching to 16.1 removes the failure, I'd agree. It's hard > > to believe that any significant number of users still care about > > building PG with xlc 12. > > Works for me. I've started a test run with the xlc version change. It failed similarly: + 23:59:00-07 | 4294966103:4294967295:00+00 | 4294966103:4294967295:00+00 | 4294966103:4294967295:00+00 + 23:59:59.99-07 | 4294966103:00:00.01+00 | 4294966103:00:00.01+00 | 4294966103:00:00.01+00
В списке pgsql-hackers по дате отправления: