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
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
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
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,
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
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
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:
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>>
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
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
28 matches
Mail list logo
