On Sat, Aug 3, 2024 at 2:11 AM David E. Wheeler wrote:
> Haven’t been following this thread, but this post reminded me of an issue I
> saw with locales on Windows[1]. Could it be that the introduction of
> Universal CRT[2] in Windows 10 has improved UTF-8 support?
Yeah. We have a few places th
On Aug 1, 2024, at 18:54, Thomas Munro wrote:
> Done (e52a44b8, 91f498fd).
>
> Any elucidation on how and why Windows machines have started using
> UTF-8 would be welcome.
Haven’t been following this thread, but this post reminded me of an issue I saw
with locales on Windows[1]. Could it be th
On Fri, Aug 2, 2024 at 1:37 AM Oleg Tselebrovskiy
wrote:
> I would appreciate if you would backpatch this change to 15 and 16
> branches.
Done (e52a44b8, 91f498fd).
Any elucidation on how and why Windows machines have started using
UTF-8 would be welcome.
Thomas Munro wrote 2024-05-12 06:31:
Hamerkop is already green on the 15 and 16 branches, apparently
because it's using the pre-meson test stuff that I guess just didn't
run the relevant test. In other words, nobody would notice the
difference anyway, and a master-only fix would be enough to end
On Fri, May 17, 2024 at 12:00 AM Alexander Lakhin wrote:
> I've tested v2 and can confirm that it works as v1, `vcregress check`
> passes with no failures on REL_16_STABLE, `meson test` with the basic
> configuration too.
Pushed, including back-branches.
This is all not very nice code and I hope
Andrew Dunstan writes:
> I've pushed a small change, that should just mark with an asterisk any
> gitref that is more than 2 days older than the tip of the branch at the
> time of reporting.
Thanks!
regards, tom lane
On 2024-05-16 Th 17:34, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-05-16 Th 17:15, Tom Lane wrote:
I'd rather have some visible status on the BF dashboard. Invariably,
with a problem like this, the animal's owner is unaware there's a
problem. If it's just silently not reporting, then n
TAKATSUKA Haruka writes:
> I'm a hamerkop maintainer.
> Sorry I have missed the scm error for so long.
> Today I switched scmrepo from git.postgresql.org/git/postgresql.git
> to github.com/postgres/postgres.git and successfully modernized
> the build target code.
Thanks very much! I see hamerk
Hello,
I'm a hamerkop maintainer.
Sorry I have missed the scm error for so long.
Today I switched scmrepo from git.postgresql.org/git/postgresql.git
to github.com/postgres/postgres.git and successfully modernized
the build target code.
with best regards, Haruka Takatsuka
On Thu, 16 May 2024 1
Andrew Dunstan writes:
> On 2024-05-16 Th 17:15, Tom Lane wrote:
>> I'd rather have some visible status on the BF dashboard. Invariably,
>> with a problem like this, the animal's owner is unaware there's a
>> problem. If it's just silently not reporting, then no one else will
>> notice either, a
On 2024-05-16 Th 17:15, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-05-16 Th 16:18, Tom Lane wrote:
Andrew: maybe the buildfarm server could be made to flag
animals building exceedingly old commits? This is the second
problem of this sort that I've noticed this month, and you
really have
Andrew Dunstan writes:
> On 2024-05-16 Th 16:18, Tom Lane wrote:
>> Andrew: maybe the buildfarm server could be made to flag
>> animals building exceedingly old commits? This is the second
>> problem of this sort that I've noticed this month, and you
>> really have to look closely to realize it's
On 2024-05-16 Th 16:18, Tom Lane wrote:
Thomas Munro writes:
For citext_utf8, I pushed cff4e5a3. Hamerkop runs infrequently, so
here's hoping for 100% green on master by Tuesday or so.
Meanwhile, back at the ranch, it doesn't seem that changed anything:
https://buildfarm.postgresql.org/cgi
Thomas Munro writes:
> For citext_utf8, I pushed cff4e5a3. Hamerkop runs infrequently, so
> here's hoping for 100% green on master by Tuesday or so.
Meanwhile, back at the ranch, it doesn't seem that changed anything:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2024-05-1
Hello Thomas,
16.05.2024 04:32, Thomas Munro wrote:
On Thu, May 16, 2024 at 10:43 AM Thomas Munro wrote:
Any chance you could test this version please Alexander?
Sorry, cancel that. v3 is not good. I assume it fixes the GSSAPI
thing and is superficially better, but it doesn't handle code th
On Thu, May 16, 2024 at 10:43 AM Thomas Munro wrote:
> Any chance you could test this version please Alexander?
Sorry, cancel that. v3 is not good. I assume it fixes the GSSAPI
thing and is superficially better, but it doesn't handle code that
calls twice in a row and ignores the first result (
On Thu, May 16, 2024 at 9:46 AM Thomas Munro wrote:
> Alright, unless anyone has an objection or ideas for improvements, I'm
> going to go ahead and back-patch this slightly tidied up version
> everywhere.
Of course as soon as I wrote that I thought of a useful improvement
myself: as far as I can
On Wed, May 15, 2024 at 6:00 PM Alexander Lakhin wrote:
> 15.05.2024 01:26, Thomas Munro wrote:
> > OK, so we know what the problem is here. Here is the simplest
> > solution I know of for that problem. I have proposed this in the past
> > and received negative feedback because it's a really gro
15.05.2024 01:26, Thomas Munro wrote:
OK, so we know what the problem is here. Here is the simplest
solution I know of for that problem. I have proposed this in the past
and received negative feedback because it's a really gross hack. But
I don't personally know what else to do about the back-
On Tue, May 14, 2024 at 9:00 PM Alexander Lakhin wrote:
> 14.05.2024 03:38, Thomas Munro wrote:
> > I was beginning to suspect that lingering odour myself. I haven't
> > look at the GSS code but I was imagining that what we have here is
> > perhaps not unsent data dropped on the floor due to ling
14.05.2024 17:38, Tom Lane wrote:
As I mentioned in our off-list discussion, I have a lingering feeling
that this v14 commit could be affecting the results somehow:
Author: Tom Lane
Branch: master Release: REL_14_BR [d5a9a661f] 2020-10-18 12:56:43 -0400
Update the Winsock API version requ
Alexander Lakhin writes:
> 13.05.2024 23:17, Tom Lane wrote:
>> 3. We don't know exactly why hamerkop suddenly started seeing these
>> failures, but a plausible theory emerges after noting that its
>> reported time for the successful "make check" step dropped pretty
>> substantially right when thi
13.05.2024 23:17, Tom Lane wrote:
3. We don't know exactly why hamerkop suddenly started seeing these
failures, but a plausible theory emerges after noting that its
reported time for the successful "make check" step dropped pretty
substantially right when this started. In the v13 branch, "make
c
On Tue, May 14, 2024 at 8:17 AM Tom Lane wrote:
> I'm not sure whether we've got unsent data pending in the problematic
> condition, nor why it'd remain unsent if we do (shouldn't the backend
> consume it anyway?). But this has the right odor for an explanation.
>
> I'm pretty hesitant to touch t
Thomas Munro writes:
> For citext_utf8, I pushed cff4e5a3. Hamerkop runs infrequently, so
> here's hoping for 100% green on master by Tuesday or so.
In the meantime, some off-list investigation by Alexander Lakhin
has turned up a good deal of information about why we're seeing
failures on hamerk
On 2024-05-12 Su 18:05, Thomas Munro wrote:
On Mon, May 13, 2024 at 12:26 AM Andrew Dunstan wrote:
Well, this is more or less where I came in back in about 2002 :-) I've been
trying to help support it ever since, mainly motivated by stubborn persistence
than anything else. Still, I agree th
On Mon, May 13, 2024 at 12:26 AM Andrew Dunstan wrote:
> Well, this is more or less where I came in back in about 2002 :-) I've been
> trying to help support it ever since, mainly motivated by stubborn
> persistence than anything else. Still, I agree that the lack of support for
> the Windows p
On 2024-05-12 Su 08:26, Andrew Dunstan wrote:
On 2024-05-12 Su 01:34, Tom Lane wrote:
BTW, I've also been wondering why hamerkop has been failing
isolation-check in the 12 and 13 branches for the last six months
or so. It is surely unrelated to this issue, and it looks like
it must be due to
On 2024-05-12 Su 01:34, Tom Lane wrote:
BTW, I've also been wondering why hamerkop has been failing
isolation-check in the 12 and 13 branches for the last six months
or so. It is surely unrelated to this issue, and it looks like
it must be due to some platform change rather than anything we
com
Hello Tom,
12.05.2024 08:34, Tom Lane wrote:
BTW, I've also been wondering why hamerkop has been failing
isolation-check in the 12 and 13 branches for the last six months
or so. It is surely unrelated to this issue, and it looks like
it must be due to some platform change rather than anything w
Thomas Munro writes:
> On Sat, May 11, 2024 at 1:14 PM Thomas Munro wrote:
>> Either way, it seems like we'll need to skip that test on Windows if
>> we want hamerkop to be green. That can probably be cribbed from
>> collate.windows.win1252.sql into contrib/citext/sql/citext_utf8.sql's
>> prelud
On Sat, May 11, 2024 at 1:14 PM Thomas Munro wrote:
> Either way, it seems like we'll need to skip that test on Windows if
> we want hamerkop to be green. That can probably be cribbed from
> collate.windows.win1252.sql into contrib/citext/sql/citext_utf8.sql's
> prelude... I just don't know how t
For example, 'i'::citext = 'İ'::citext fails to be true.
It must now be using UTF-8 (unlike, say, Drongo) and non-C ctype,
given that the test isn't skipped. This isn't the first time that
we've noticed that Windows doesn't seem to know about İ→i (see [1]),
but I don't think anyone has explained
33 matches
Mail list logo
