Andres Freund writes:
> On 2023-10-19 10:38:14 -0400, Robert Haas wrote:
>> To be honest, I'm not entirely sure that even AIX gcc support is
>> delivering enough value per unit work to justify keeping it around.
>> But the xlc situation is worse.
> Agreed with both. If it were just a platform tha
Hi,
On 2023-10-19 10:38:14 -0400, Robert Haas wrote:
> On Wed, Oct 18, 2023 at 7:33 PM Noah Misch wrote:
> > I feel the gravity and longevity of xlc bugs has been out of proportion with
> > the compiler's contribution to PostgreSQL. I would find it reasonable to
> > revoke xlc support in v17+, l
Robert Haas writes:
> On Wed, Oct 18, 2023 at 7:33 PM Noah Misch wrote:
>> I feel the gravity and longevity of xlc bugs has been out of proportion with
>> the compiler's contribution to PostgreSQL. I would find it reasonable to
>> revoke xlc support in v17+, leaving AIX gcc support in place.
>
On Wed, Oct 18, 2023 at 7:33 PM Noah Misch wrote:
> I feel the gravity and longevity of xlc bugs has been out of proportion with
> the compiler's contribution to PostgreSQL. I would find it reasonable to
> revoke xlc support in v17+, leaving AIX gcc support in place.
+1 for this proposal. I just
On Wed, Oct 18, 2023 at 04:45:46PM -0400, Tom Lane wrote:
> > On Wed, Oct 18, 2023 at 12:02 PM Tom Lane wrote:
> >> Probably. Independent of that, it's fair to ask why we're still
> >> testing against xlc 12.1 and not the considerably-more-recent xlclang,
> >> or at least xlc 16.1. (I also wonde
Robert Haas writes:
> On Wed, Oct 18, 2023 at 12:02 PM Tom Lane wrote:
>> Probably. Independent of that, it's fair to ask why we're still
>> testing against xlc 12.1 and not the considerably-more-recent xlclang,
>> or at least xlc 16.1. (I also wonder why we're still testing AIX 7.1
>> rather t
On Wed, Oct 18, 2023 at 12:02 PM Tom Lane wrote:
> Probably. Independent of that, it's fair to ask why we're still
> testing against xlc 12.1 and not the considerably-more-recent xlclang,
> or at least xlc 16.1. (I also wonder why we're still testing AIX 7.1
> rather than an OS version that's no
Robert Haas writes:
> On Tue, Oct 17, 2023 at 7:35 PM Tom Lane wrote:
>> Discounting the Windows animals, it looks like the xlc animals are
>> our only remaining ones that use anything except gcc or clang.
> After some research I determined that the release date for xlc 12.1
> seems to be June 1
On Tue, Oct 17, 2023 at 7:35 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote:
> >> Should we be testing against xlclang instead?
>
> > I hesitated to suggest it because it's not my animal/time we're
> > talking about but it seems to make more sense.
Thomas Munro writes:
> On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote:
>> Should we be testing against xlclang instead?
> I hesitated to suggest it because it's not my animal/time we're
> talking about but it seems to make more sense. It appears to be IBM's
> answer to the nothing-builds-with-
On Tue, Oct 17, 2023 at 12:45:28PM -0400, Tom Lane wrote:
> Whoops, no: for negative starting values we'd need truncate-towards-
> minus-infinity division whereas C99 specifies truncate-towards-zero.
> However, the attached does pass for me on cfarm111 as well as my
> usual dev machine.
I guess th
Thomas Munro writes:
> On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote:
>> Should we be testing against xlclang instead?
> I hesitated to suggest it because it's not my animal/time we're
> talking about but it seems to make more sense. It appears to be IBM's
> answer to the nothing-builds-with-
On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote:
> Thomas Munro writes:
>
> > Given that IBM describes xlc as "legacy" (replaced by xlclang, but
> > still supported for some unspecified period of time for the benefit of
> > people who need C++ ABI compatibility with old code), I wonder how
> > lo
Thomas Munro writes:
> Given that IBM describes xlc as "legacy" (replaced by xlclang, but
> still supported for some unspecified period of time for the benefit of
> people who need C++ ABI compatibility with old code), I wonder how
> long we plan to support it...
Should we be testing against xlc
Hmm, I guess I must have missed some important flag or environment
variable when trying to reproduce it, sorry.
Given that IBM describes xlc as "legacy" (replaced by xlclang, but
still supported for some unspecified period of time for the benefit of
people who need C++ ABI compatibility with old c
I wrote:
> Yeah, the same thing occurred to me in the shower this morning, and it
> does seem to work! We can replace both loops with a %= operator, at
> least if we're willing to assume C99 division semantics, which seems
> pretty safe in 2023.
Whoops, no: for negative starting values we'd need
Michael Paquier writes:
> On Tue, Oct 17, 2023 at 01:40:18AM -0400, Tom Lane wrote:
>> makes the failure go away. Unfortunately, I've not yet found another
>> way to make it go away :-(. My upthread idea of using a local variable
>> instead of result->time is no help, and some other random code
On Tue, Oct 17, 2023 at 01:40:18AM -0400, Tom Lane wrote:
> makes the failure go away. Unfortunately, I've not yet found another
> way to make it go away :-(. My upthread idea of using a local variable
> instead of result->time is no help, and some other random code
> alterations didn't change th
Noah Misch writes:
> On Mon, Oct 16, 2023 at 01:54:23AM -0400, Tom Lane wrote:
>> Ugh. So if the failure is robust enough to persist across
>> several major xlc versions, why couldn't Thomas reproduce it?
> Beats me. hornet wipes its starting environment down to OBJECT_MODE=32_64
> PERL5LIB=/ho
Michael Paquier writes:
> On Mon, Oct 16, 2023 at 09:54:41AM -0400, Tom Lane wrote:
>> I'm mighty tempted though to (a) add coverage for timetz_izone
>> to HEAD, and (b) backpatch the new tests, sans the AT LOCAL case,
>> to the back branches (maybe not v11).
> I see that you've already done (a)
On Mon, Oct 16, 2023 at 09:54:41AM -0400, Tom Lane wrote:
> I'm mighty tempted though to (a) add coverage for timetz_izone
> to HEAD, and (b) backpatch the new tests, sans the AT LOCAL case,
> to the back branches (maybe not v11).
I see that you've already done (a) with 2f04720307. I'd be curious
Michael Paquier writes:
> Perhaps that's a stupid question.. But a server running under this
> environment fails the two following queries even for older branches,
> right?
> select timezone('UTC', '23:59:59.99-07'::timetz);
> select timezone('UTC', '23:59:00-07'::timetz);
One would expect, sinc
On Sun, Oct 15, 2023 at 11:05:10PM -0700, Noah Misch wrote:
> On Mon, Oct 16, 2023 at 01:54:23AM -0400, Tom Lane wrote:
>> Ugh. So if the failure is robust enough to persist across
>> several major xlc versions, why couldn't Thomas reproduce it?
>
> Beats me. hornet wipes its starting environmen
On Mon, Oct 16, 2023 at 01:54:23AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Oct 15, 2023 at 09:58:04PM -0700, Noah Misch wrote:
> >> 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
Noah Misch writes:
> On Sun, Oct 15, 2023 at 09:58:04PM -0700, Noah Misch wrote:
>> 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:
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 writes:
> > > On Mon, Oct 16, 2023 at 4:02 PM Tom Lane wrote:
> > >> I'm having a hard time not believing that this is a compiler bug.
> > >> Looking back at 8d
On Sun, Oct 15, 2023 at 11:30:17PM -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Oct 16, 2023 at 4:02 PM Tom Lane 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 r
On Sun, Oct 15, 2023 at 11:30:17PM -0400, Tom Lane wrote:
> Thomas Munro writes:
>> 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 sign
Thomas Munro writes:
> On Mon, Oct 16, 2023 at 4:02 PM Tom Lane 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 t
On Mon, Oct 16, 2023 at 4:02 PM Tom Lane 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 l
Thomas Munro writes:
> On Mon, Oct 16, 2023 at 2:58 PM Michael Paquier 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 shipp
On Mon, Oct 16, 2023 at 2:58 PM Michael Paquier 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 av
On Mon, Oct 16, 2023 at 11:50:08AM +1300, Thomas Munro wrote:
> On Mon, Oct 16, 2023 at 11:24 AM Thomas Munro wrote:
>> On Mon, Oct 16, 2023 at 10:57 AM Tom Lane wrote:
>>> I'm tempted to wonder if this helps:
>>>
>>> - result->time = t->time + (t->zone - tz) * USECS_PER_SEC;
>>> + re
On Sun, Oct 15, 2023 at 06:47:04PM -0400, Tom Lane wrote:
> Another possibly interesting factoid: it appears that before
> 97957fdba, we had zero regression test coverage of timetz_zone ---
> and we still have none of timetz_izone, which contains essentially
> the same code. So if there is a probl
On Mon, Oct 16, 2023 at 11:24 AM Thomas Munro wrote:
> On Mon, Oct 16, 2023 at 10:57 AM Tom Lane wrote:
> > I'm tempted to wonder if this helps:
> >
> > - result->time = t->time + (t->zone - tz) * USECS_PER_SEC;
> > + result->time = t->time + (int64) (t->zone - tz) * USECS_PER_SEC;
>
Another possibly interesting factoid: it appears that before
97957fdba, we had zero regression test coverage of timetz_zone ---
and we still have none of timetz_izone, which contains essentially
the same code. So if there is a problem here, whether it's ours or
the compiler's, it's not hard to see
On Mon, Oct 16, 2023 at 10:57 AM Tom Lane wrote:
> I'm tempted to wonder if this helps:
>
> - result->time = t->time + (t->zone - tz) * USECS_PER_SEC;
> + result->time = t->time + (int64) (t->zone - tz) * USECS_PER_SEC;
I wanted to be able to try this and any other theories and manage
Thomas Munro writes:
> One of the AIX animals gave a strange result here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2023-10-15%2011%3A40%3A01
> If you ignore the diffs due to change in column width, the interesting
> change seems to be:
> - 23:59:00-07| 06:59:00+00
One of the AIX animals gave a strange result here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2023-10-15%2011%3A40%3A01
If you ignore the diffs due to change in column width, the interesting
change seems to be:
- 23:59:00-07| 06:59:00+00| 06:59:00+00| 06:59:00
On Fri, Oct 13, 2023 at 07:03:20AM +0200, Vik Fearing wrote:
> Thank you, Michael君!
No pb, ヴィックさん。
--
Michael
signature.asc
Description: PGP signature
On 10/13/23 05:07, Michael Paquier wrote:
On Fri, Oct 13, 2023 at 02:20:59AM +0200, Vik Fearing wrote:
On 10/10/23 05:34, Michael Paquier wrote:
I am attaching a v5 that addresses the documentation bits, could you
look at the business with date.c?
Here is a v6
Thanks for the new version.
On Fri, Oct 13, 2023 at 02:20:59AM +0200, Vik Fearing wrote:
> On 10/10/23 05:34, Michael Paquier wrote:
> > I am attaching a v5 that addresses the documentation bits, could you
> > look at the business with date.c?
>
> Here is a v6
Thanks for the new version.
> which hopefully addresses all of
From: Vik Fearing
Date: Wed, 4 Oct 2023 15:46:38 +0100
Subject: [PATCH v6] Add support for AT LOCAL
When converting a timestamp to/from with/without time zone, the SQL
Standard specifies an AT LOCAL variant of AT TIME ZONE which uses the
session's time zone.
---
doc/src/sgml/func
bits, could you
look at the business with date.c?
--
Michael
From e136d38967a863452762e1ee6e28d9ab40056adf Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 10 Oct 2023 13:28:46 +0900
Subject: [PATCH v5] Add support for AT LOCAL with timestamps
When converting a timestamp to/from with/without t
using AT LOCAL is correctly
reproduced by ruleutils.c.
The attached v4 changes the regression tests (and nothing else).
--
Vik Fearing
From 03273214f0320e347a0b012763dc82cd91ae6775 Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Wed, 4 Oct 2023 15:46:38 +0100
Subject: [PATCH v4] Add support f
On Wed, Oct 04, 2023 at 03:49:03PM +0100, Vik Fearing wrote:
> Okay. Here is a v3 using that approach.
You have not posted any numbers to show if there's a difference in
performance, so I have run a simple test:
PREPARE test AS SELECT TIMESTAMP '1978-07-07 19:38' AT LOCAL;
DO $$ BEGIN
FOR i IN
2001
From: Vik Fearing
Date: Wed, 4 Oct 2023 15:46:38 +0100
Subject: [PATCH v3] Add support for AT LOCAL
When converting a timestamp to/from with/without time zone, the SQL
Standard specifies an AT LOCAL variant of AT TIME ZONE which uses the
session's time zone.
---
doc/src/sgml/func.sgml
On Tue, Oct 03, 2023 at 02:10:48AM +0200, Vik Fearing wrote:
> On 9/29/23 09:27, Michael Paquier wrote:
>> As the deparsing code introduced by this patch is showing, this leads
>> to a lot of extra complexity. And, actually, this can be quite
>> expensive as well with these two layers of functions
On 9/29/23 09:27, Michael Paquier wrote:
On Sat, Sep 23, 2023 at 12:54:01AM +0200, Vik Fearing wrote:
On 9/22/23 23:46, cary huang wrote:
I think this feature can be a useful addition in dealing with time
zones. I have applied and tried out the patch, The feature works as
described and seems pr
On Sat, Sep 23, 2023 at 12:54:01AM +0200, Vik Fearing wrote:
> On 9/22/23 23:46, cary huang wrote:
>> I think this feature can be a useful addition in dealing with time
>> zones. I have applied and tried out the patch, The feature works as
>> described and seems promising. The problem with compilat
On 9/22/23 23:46, cary huang wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello
I think this fea
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello
I think this feature can be a useful addition in deali
On 7/3/23 15:42, Daniel Gustafsson wrote:
On 6 Jun 2023, at 05:13, Vik Fearing wrote:
Patch against 3f1180 attached.
This patch fails to compile, the declaration of variables in the switch block
needs to be scoped within a { } block.
Interesting. It compiles for me.
I've fixed th
> On 6 Jun 2023, at 05:13, Vik Fearing wrote:
> Patch against 3f1180 attached.
This patch fails to compile, the declaration of variables in the switch block
needs to be scoped within a { } block. I've fixed this trivial error in the
attached v2 and also reflowed the comments which now no lo
On 6/12/23 17:37, Alvaro Herrera wrote:
On 2023-Jun-06, Laurenz Albe wrote:
At a quick glance, it looks like you resolve "timezone" at the time
the query is parsed. Shouldn't the resolution happen at query
execution time?
Sounds like it -- consider the case where the timestamp value is a
par
On 2023-Jun-06, Laurenz Albe wrote:
> At a quick glance, it looks like you resolve "timezone" at the time
> the query is parsed. Shouldn't the resolution happen at query
> execution time?
Sounds like it -- consider the case where the timestamp value is a
partition key and one of the partition bo
On Tue, 2023-06-06 at 04:24 -0400, Vik Fearing wrote:
> > At a quick glance, it looks like you resolve "timezone" at the time
> > the query is parsed. Shouldn't the resolution happen at query
> > execution time?
>
> current_setting(text) is stable, and my tests show that it is calculated
> at ex
On 6/6/23 03:56, Laurenz Albe wrote:
On Mon, 2023-06-05 at 23:13 -0400, Vik Fearing wrote:
The Standard defines time zone conversion as follows:
::=
[ ]
::=
AT
::=
LOCAL
| TIME ZONE
While looking at something else, I noticed we do not support AT LOCAL.
The local tim
On Mon, 2023-06-05 at 23:13 -0400, Vik Fearing wrote:
> The Standard defines time zone conversion as follows:
>
> ::=
> [ ]
>
> ::=
> AT
>
> ::=
> LOCAL
> | TIME ZONE
>
>
> While looking at something else, I noticed we do not support AT LOCAL.
> The local time zone is def
in views where the view will
automatically adjust to the session's time zone.
Patch against 3f1180 attached.
--
Vik FearingFrom b8317f3070c11df1e2ad791bd8d823aaae66dbe4 Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Mon, 5 Jun 2023 19:42:42 -0400
Subject: [PATCH v1] Add support f
60 matches
Mail list logo
