On Wed, Oct 30, 2024 at 7:20 PM Tom Lane wrote:
> I wrote:
> > So the problem is precisely that *our* interpretation of EST5EDT
> > changed when we adopted tzdata 2024b, and that is affecting how
> > we dump these old timestamps. Or at least, that seems like what
> > should be happening, but the
I wrote:
> So the problem is precisely that *our* interpretation of EST5EDT
> changed when we adopted tzdata 2024b, and that is affecting how
> we dump these old timestamps. Or at least, that seems like what
> should be happening, but then why is only crake showing a failure?
Oh, got it: of the m
I wrote:
> ... So I'm fuzzy about the exact details of
> what has happened on crake, but I'm pretty sure that it boils
> down to "the dump timezone changed since 2018".
Oh ... never mind, I was thinking in terms of what would happen
with --use-system-timezone, but of course the buildfarm doesn't
b
Andrew Dunstan writes:
> On Wed, Oct 30, 2024 at 4:53 PM Andrew Dunstan wrote:
>> My 9.2 saved instance is quite old ... Nov 2018.
>> But I don't see why that should affect it, so I'm confused too.
> Further data point - drongo and fairywren are not showing this issue.
My 9.2 reference instance
On Wed, Oct 30, 2024 at 4:53 PM Andrew Dunstan wrote:
>
>
> On Wed, Oct 30, 2024 at 4:33 PM Tom Lane wrote:
>
>> Andrew Dunstan writes:
>> > On Wed, Oct 30, 2024 at 11:00 AM Tom Lane wrote:
>> >> I went to try to test this locally, and got nowhere, because:
>> >> old cluster does not use
Andrew Dunstan writes:
> On Wed, Oct 30, 2024 at 11:00 AM Tom Lane wrote:
>> I went to try to test this locally, and got nowhere, because:
>> old cluster does not use data checksums but the new one does
>> Failure, exiting
>> What have you done to get around that on crake?
> I did this
On Wed, Oct 30, 2024 at 11:00 AM Tom Lane wrote:
> Andrew Dunstan writes:
> > On Oct 29, 2024, at 5:41 PM, Tom Lane wrote:
> >> I would expect that the upgrade tests would pass now for upgrades
> >> from v12 or later, thanks to b8ea0f675 et al, but I'm not real
> >> sure what to do about testin
Andrew Dunstan writes:
> On Oct 29, 2024, at 5:41 PM, Tom Lane wrote:
>> I would expect that the upgrade tests would pass now for upgrades
>> from v12 or later, thanks to b8ea0f675 et al, but I'm not real
>> sure what to do about testing the out-of-support branches. Should
>> we back-patch b8ea0
> On Oct 29, 2024, at 5:41 PM, Tom Lane wrote:
>
> Andrew Dunstan writes:
>> Crake doesn't seem to like this for cross version upgrade, and the diff
>> looks rather odd:
>
> Oh, that's annoying. I forgot to mention the side-effects that 2024b
> had on PST8PDT and other SysV-derived timezo
Andrew Dunstan writes:
> Crake doesn't seem to like this for cross version upgrade, and the diff
> looks rather odd:
Oh, that's annoying. I forgot to mention the side-effects that 2024b
had on PST8PDT and other SysV-derived timezones (probably because Paul
Eggert avoided mentioning that in his r
On Tue, Oct 29, 2024 at 11:50 AM Tom Lane wrote:
> Update time zone data files to tzdata release 2024b.
>
> Historical corrections for Mexico, Mongolia, and Portugal.
> Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar
> rather than being a separate zone, mainly because the difference
Update time zone data files to tzdata release 2024b.
Historical corrections for Mexico, Mongolia, and Portugal.
Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar
rather than being a separate zone, mainly because the differences
between those zones were found to be based on untrustworth
Update time zone data files to tzdata release 2024b.
Historical corrections for Mexico, Mongolia, and Portugal.
Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar
rather than being a separate zone, mainly because the differences
between those zones were found to be based on untrustworth
Update time zone data files to tzdata release 2024b.
Historical corrections for Mexico, Mongolia, and Portugal.
Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar
rather than being a separate zone, mainly because the differences
between those zones were found to be based on untrustworth
Update time zone data files to tzdata release 2024b.
Historical corrections for Mexico, Mongolia, and Portugal.
Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar
rather than being a separate zone, mainly because the differences
between those zones were found to be based on untrustworth
Update time zone data files to tzdata release 2024b.
Historical corrections for Mexico, Mongolia, and Portugal.
Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar
rather than being a separate zone, mainly because the differences
between those zones were found to be based on untrustworth
Update time zone data files to tzdata release 2024b.
Historical corrections for Mexico, Mongolia, and Portugal.
Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar
rather than being a separate zone, mainly because the differences
between those zones were found to be based on untrustworth
Update time zone data files to tzdata release 2024b.
Historical corrections for Mexico, Mongolia, and Portugal.
Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar
rather than being a separate zone, mainly because the differences
between those zones were found to be based on untrustworth
18 matches
Mail list logo
