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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: UniqueKey v2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Add support for AT LOCAL