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
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 which hopefully addresses all of your concerns.
--
Vik Fearing
From 042ce9b581ca3b17afbf229d209ca59addb6c9a2 Mon Sep 17 00:00:00 2001
Fro
On Sat, Oct 07, 2023 at 02:35:06AM +0100, Vik Fearing wrote:
> I realized that my regression tests are not exercising what I originally
> intended them to after this change. They are supposed to show that calling
> the function explicitly or using AT LOCAL is correctly reproduced by
> ruleutils.c.
On 10/6/23 07:05, Michael Paquier wrote:
I haven't yet finished my review of the patch, still looking at it.
I realized that my regression tests are not exercising what I originally
intended them to after this change. They are supposed to show that
calling the function explicitly or using A
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
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 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
59 matches
Mail list logo
