Hello hackers,
Please take a look at the August report on buildfarm failures:
# SELECT br, COUNT(*) FROM failures WHERE dt >= '2025-08-01' AND
dt < '2025-09-01' GROUP BY br;
REL_13_STABLE: 9
REL_14_STABLE: 8
REL_15_STABLE: 6
REL_16_STABLE: 12
REL_17_STABLE: 13
REL_18_STABLE: 16
master: 38
-- Tot
Hello hackers,
I've noticed several timeout failures occurred during this month on
sidewinder: [1] [2] [3].
All three hangs happened at test thread/alloc:
...
ok 60 - thread/thread 95 ms
ok 61 - thread/thread_implicit 89 ms
ok 62
Hello Alexander,
24.08.2025 03:44, Alexander Korotkov wrote:
Thank you for catching this. And thank you for the fix. I think it
worth separating fix and refactoring. This helps to understand what
exactly the fix is by looking at the patch. I also edited commit
message. I'm going to push thi
Hello Andres,
22.07.2025 02:19, Andres Freund wrote:
Hi,
On 2025-06-19 10:16:12 -0500, Nico Williams wrote:
On Thu, Jun 19, 2025 at 05:05:25PM +0200, Daniel Gustafsson wrote:
I also dug out an archeologically old MacBook Pro running macOS High Sierra
10.13.6 with an i5 using Apple LLVM versio
Hello Noah,
04.08.2025 03:03, Noah Misch wrote:
Pushed as 0decd5e. ...
Please look at a new anomaly introduced with that commit. The following
script:
createdb regression
echo "
CREATE USER u1;
ALTER DEFAULT PRIVILEGES FOR ROLE u1 REVOKE INSERT ON TABLES FROM u1;
CREATE USER u2;
ALTER DEFAU
Hello hackers,
Please take a look at the July report on buildfarm failures:
# SELECT br, COUNT(*) FROM failures WHERE dt >= '2025-07-01' AND
dt < '2025-08-01' GROUP BY br;
REL_13_STABLE: 4
REL_14_STABLE: 2
REL_15_STABLE: 4
REL_16_STABLE: 3
REL_17_STABLE: 4
REL_18_STABLE: 9
master: 42
-- Total: 6
Hello Noah,
07.07.2025 22:26, Noah Misch wrote:
A 002_pg_upgrade.pl run got swapped order of tags "notnull_tbl1_upg nn" and
"notnull_parent_upg nn" for the schema diff test that commit
172259afb563d35001410dc6daad78b250924038 added in v18:
@@ -436873,14 +436873,14 @@
ALTER TABLE public.insert
Hello Nazir and Michael!
01.07.2025 10:57, Nazir Bilal Yavuz wrote:
I agree with you. So, the current logic is:
If primary is not alive: Do not report anything.
If only primary is alive: Report the entire diff file.
If both primary and standby are alive: Report entire diff file and add
head+tai
Hello Kuroda-san and Takatsuka-san,
24.07.2025 03:49, TAKATSUKA Haruka wrote:
{snip}
Maybe you could try tools.syncTime = "0" by any chance?
It has been already tools.syncTime = "0" so far.
I confirmed the following GUI setting.
...
23.07.2025 09:15, Hayato Kuroda (Fujitsu) wrote:
It looks
Hello Takatsuka-san,
23.07.2025 08:48, TAKATSUKA Haruka wrote:
Hello Alexander,
On Wed, 23 Jul 2025 00:55:37 +
Yugo Nagata - Buildfarm wrote:
Nagata-san, could you please share the configuration of hamerkop? If it's
running inside VM, what virtualization software is used?
It's vmware ESX
Hello Kuroda-san,
20.07.2025 11:00, Alexander Lakhin wrote:
Yeah, I made a simple test for GetSystemTimePreciseAsFileTime() and
confirmed that in my VM it provides sub-microsecond precision. Regarding
NTP, I think the second failure of this ilk [1] makes this cause close to
impossible. (Can&#
Hello Kuroda-san,
Thank you for your attention to this!
15.07.2025 10:33, Hayato Kuroda (Fujitsu) wrote:
GetSystemTimePreciseAsFileTime() returns FILETIME structure, which represents
the
time UTC with 100-nanosecod intervals [1]. The stack overflow seemed to refer
it.
However, the document fo
Hello Michail,
07.07.2025 03:18, Michael Paquier wrote:
I'm failing to reproduce it, unfortunately. It looks like just a
timing issue with the reports, so the best option I can think of here
would be to switch the test to do a wait until the stats have been
generated, leading to the attached.
Hello hackers,
A couple of the 002.blocks test's failures occurred during past three
months: [1], [2] with the following diagnostics:
# Failed test 'WAL summarizer generates statistics for WAL reads'
# at
/home/bf/bf-build/culicidae/REL_18_STABLE/pgsql/src/bin/pg_walsummary/t/002_blocks.pl
Hello hackers,
The recent buildfarm failure [1] on REL_15_STABLE with the following
diagnostics:
# Looks like your test exited with 29 just after 1.
t/024_add_drop_pub.pl ..
Dubious, test returned 29 (wstat 7424, 0x1d00)
pgsql.build/src/test/subscription/tmp_check/log/regress_log_024
Hello Andrew,
I've noticed that prion fails with timeout rather frequently this week.
Probably this is caused just by increased total number and duration of
tests, as we can see timeouts at different stages:
[1]
# +++ tap install-check in src/test/modules/test_misc +++
t/001_constraint_validation
Hello Shlok,
03.07.2025 09:54, Shlok Kyal wrote:
I have also encountered a similar buildfarm failure [1].
| 1/1 + subscription 142 ms FAIL
1/1 postgresql:regress / regress/regress ERROR 284.85s exit status 1
diff --strip-trailing-cr -U3
c:/build-farm-lo
Hello hackers,
Please take a look at the June report on buildfarm failures:
# SELECT br, COUNT(*) FROM failures WHERE dt >= '2025-06-01' AND
dt < '2025-07-01' GROUP BY br;
REL_13_STABLE: 4
REL_14_STABLE: 3
REL_15_STABLE: 4
REL_16_STABLE: 6
REL_17_STABLE: 4
REL_18_STABLE: 1
master: 54
-- Total: 7
15.06.2025 14:02, Alexander Korotkov wrote:
Could you, please, check this patch? On my system it makes 046 and
047 execute in 140 secs with -O0 and -DRELCACHE_FORCE_RELEASE
-DCATCACHE_FORCE_RELEASE.
Thank you for the patch!
It decreases the test's duration significantly:
# +++ tap check in sr
Hello Alexander,
10.06.2025 23:14, Alexander Korotkov wrote:
So, my proposal is to commit the attached patchset to the HEAD, and
commit [1] to the back branches. Any objections?
As the buildfarm animal prion shows [1], the 046_checkpoint_logical_slot
test fails with "-DRELCACHE_FORCE_RELEASE
Hello Peter,
06.06.2025 19:33, Peter Geoghegan wrote:
On Wed, Jun 4, 2025 at 1:39 PM Peter Geoghegan wrote:
My current plan is to commit this in the next couple of days.
Pushed.
Please look at the following script, which falsifies an assertion
introduced with e6eed40e4:
create user u;
grant
Hello David,
24.12.2024 03:57, David Rowley wrote:
On Tue, 24 Dec 2024 at 11:19, David Rowley wrote:
The attached adjusts that Assert code so that a fresh CompactAttribute
is populated instead of modifying the TupleDesc's one. I'm not sure
if populate_compact_attribute_internal() is exactly th
s of this kind be accessed from another database? Determines
* whether a stats object gets included in stats snapshots.
*/
bool accessed_across_databases:1;
/* Should stats be written to the on-disk stats file? */
bool write_to_file:1;
...
Best regards,
Alexander Lakhin
Hello,
05.06.2025 22:00, Alexander Lakhin wrote:
Thank you for your attention to this and for the tip! Today I tried the
following:
--- a/src/include/storage/aio.h
+++ b/src/include/storage/aio.h
@@ -89,8 +89,8 @@ typedef enum PgAioOp
/* intentionally the zero value, to help catch
Hello Thomas and Andres,
04.06.2025 23:32, Thomas Munro wrote:
On Thu, Jun 5, 2025 at 8:02 AM Andres Freund wrote:
On 2025-06-03 08:00:01 +0300, Alexander Lakhin wrote:
2025-06-03 00:19:09.282 EDT [25175:1] LOG: !!!pgaio_io_before_start| ioh:
0x104c3e1a0, ioh->op: 1, ioh->state:
Hello,
02.06.2025 09:00, Alexander Lakhin wrote:
With additional logging (the patch is attached), I can see the following:
...
!!!pgaio_io_reclaim [63817]| ioh: 0x1046b5660, ioh->op: 1, ioh->state: 6,
ioh->result: 8192, ioh->num_callbacks: 2
!!!AsyncReadBuffers [63817] (1)| block
31.05.2025 06:00, Alexander Lakhin wrote:
Hello Thomas,
It looks like I managed to restore all the conditions needed to reproduce
that Assert more or less reliably (within a couple of hours), so I can
continue experiments.
I've added the following debugging:
...
With additional logging
%40luirh3vxbehp
: 9
https://www.postgresql.org/message-id/ca+hukgl0bikwsc2xw-zugfwnvepd_gewxndi2pe5twqmapk...@mail.gmail.com
: 3
# SELECT count(*) FROM failures WHERE dt >= '2025-05-01' AND
dt < '2025-06-01' AND issue_link IS NULL; -- Unsorted/unhelpful failures
42
Short-lived failures: 17
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
g
directly.
I use MacBook M1 and don't know how to disable E/P-cores, moreover, from
my observation, the test performs slower (up to 10%) when it runs for
hours in a loop, probably because of the CPU heating up and lowering
it's frequency, so if the issue is really timing-dependent, it
a patch to repeat "test: brin" line, but I'm not sure
it does matter.
Sorry for the lack of useful information again.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
_INSTALL=1 make
-s check -s -C src/test/recovery_{} ::: `seq 8` || break; done; echo -e "\007"
Alexander Lakhin
Neon (https://neon.tech)
19a%40gmail.com
Maybe you would also find relevant this thread:
https://www.postgresql.org/message-id/flat/ZiYjn0eVc7pxVY45%40ip-10-97-1-34.eu-west-3.compute.internal
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
uildfarm, but this one looks
interesting too.
(I can share the complete patch + script for such testing, if it can be
helpful.)
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
o maybe it's a MacOS-specific issue. I will try to get an access
to a similar machine to reproduce it there.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
XX000: unexpected virtual generated column reference
LOCATION: CheckVarSlotCompatibility, execExprInterp.c:2410
Shouldn't this be expected/supported?
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
dqjwb2sfqzcgs22lf%40ok2gletdaoe6
: 30
-- Fixed
SELECT count(*) FROM failures WHERE dt >= '2025-04-01' AND
dt < '2025-05-01' AND issue_link IS NULL; -- Unsorted/unhelpful failures
13
Short-lived failures: 238
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
ons, I observed also other memory-context-
related crashes.
(Probably this effect is achieved just because of the performance
optimization -- I haven't look deeper yet.)
This issue is discovered with SQLsmith.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
in the case [2], it could be helpful.
[1]
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#Upgrade_tests_fail_on_Windows_due_to_pg_upgrade_output.d.2F_not_removed
[2]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=copperhead&dt=2025-02-20%2017%3A01%3A23
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
@{$cmd}) . "\n");
my $result = IPC::Run::run $cmd, '>' => \$stdout, '2>' => \$stderr;
if (!$result)
{
like($stdout, $expected_stdout, "$test_name: stdout matches");
like($stderr, $expected_stderr, "$test_name: stderr m
Hello Andres,
24.04.2025 03:40, Andres Freund wrote:
Hi,
On 2025-04-20 18:00:00 +0300, Alexander Lakhin wrote:
2025-04-08 01:41:54.670 UTC [4013251][client backend][0/2:0] DEBUG: waiting for
self with 0 pending
I'd like to extend this debug message with the number of in-flight IO
advance_aggregates (aggstate=aggstate@entry=0x6310011e14f8) at nodeAgg.c:820
#20 0x630ff291db18 in agg_retrieve_direct (aggstate=0x6310011e14f8) at
nodeAgg.c:2540
#21 ExecAgg (pstate=0x6310011e14f8) at nodeAgg.c:2265
#22 0x630ff290deef in ExecProcNodeFirst (node=0x6310011e14f8) at
execProcnode.c:469
...
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
GIN_TUPLE_ -> GIN_TUPLE_H
This one is interested. It should be harmless in practice, but it
could cause conflicts in theory.
--
I've included it in the collection because of:
#ifndef GIN_TUPLE_
...
#endif /* GIN_TUPLE_H */
Best regards
gt; sync_queue_destroy
thats -> that's
ther -> there
test-server -> test server
unfronzen -> unfrozen
upin -> unpin
Please find attached the complete patch for your convenience.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)diff --git a/contrib/amcheck/verify_common.h b/c
you for the analysis!
I think you're right, it's the same issue, so I've added the link to the
wiki page.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
org/message-id/b62f97b1-bbff-42cd-861f-c785f0774ab8%40gmail.com
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#001_rep_changes.pl_fails_due_to_publisher_stuck_on_shutdown
and is not related to the Memoize paths.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
ere recently merged. Namely
support for readv/writev of "fixed" buffers. That avoids needing to pin/unpin
buffers while IO is ongoing, which turns out to be a noticeable bottleneck in
some workloads, particularly when using 1GB huge pages.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
repro.tar.gz
Description: application/gzip
/buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-04-11%2007%3A41%3A36
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
Hello Andres,
07.04.2025 22:10, Alexander Lakhin wrote:
I ran it for a while in a VM, it hasn't triggered yet. Neither on xfs nor on
tmpfs.
Before sharing the script I tested it on two my machines, but I had
anticipated that the error can be hard to reproduce. Will try to reduc
ntry=true, count=0,
count@entry=9223372036854775807,
dest=dest@entry=0x5910bddf6070) at pquery.c:953
#20 0x591086dab83b in PortalRun (portal=portal@entry=0x5910bdd72f10, count=count@entry=9223372036854775807,
isTopLevel=isTopLevel@entry=true,
dest=dest@entry=0x5910bddf6070, altdest=altdest@entry=0x5910bddf6070,
qc=qc@entry=0x7ffcf961c9f0) at pquery.c:797
#21 0x591086da74a4 in exec_simple_query (query_string=query_string@entry=0x5910bdcebe60 "SELECT COUNT(*) >= 0 AS ok
FROM pg_aios;") at postgres.c:1274
But I'm yet to construct a more reliable reproducer for it. Hope I could
do this during the current week.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
es in(1);
It's reproduced better on tmpfs for me; probably you would need to increase
NUM_INSTALLCHECKS/NUM_ITERATIONS for your machine. I can reduce the testing
procedure to something trivial, if it makes sense for you. Probably, the
same effect can be also achieved with just pgbench...
05.04.2025 00:47, Tom Lane wrote:
Alexander Lakhin writes:
I've stumbled upon another defect introduced with 0dca5d68d:
CREATE FUNCTION f(VARIADIC ANYARRAY) RETURNS ANYELEMENT AS $$ SELECT x FROM
generate_series(1,1) g(i) $$ LANGUAGE SQL
IMMUTABLE;
SELECT f(1);
SELECT f(1);
Hmm,
by 0x41EB54: ExecInterpExprStillValid
(execExprInterp.c:2299)
...
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
n type mismatch in function declared to return integer[]
DETAIL: Function's final statement must be SELECT or
INSERT/UPDATE/DELETE/MERGE RETURNING.
CONTEXT: SQL function "f" during startup
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
GR-ng0nqGG0yemR_ufdg3%2Bv3gkPa6Nc2ntnrA%40mail.gmail.com
: 10
-- Fixed
https://www.postgresql.org/message-id/m2gyjjk6hazud7hezz25t7aw7rjv73fthkct4jqbvrnu3ezqz3%40nx3m53r7scce
: 10
-- Fixed
SELECT count(*) FROM failures WHERE dt >= '2025-03-01' AND
dt < '2025-04-01' AND issue_link IS
text) INHERITS (a);
CREATE TABLE d (dd text) INHERITS (c, a);
ALTER TABLE a ADD COLUMN i int DEFAULT 1;
fails with:
ERROR: XX000: tuple already updated by self
LOCATION: simple_heap_update, heapam.c:4421
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
ord OK 383.50s 3
subtests passed
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-03-09%2020%3A23%3A09
- REL_17_STABLE
[2]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-03-14%2013%3A52%3A09
- master
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
cutor/execProcnode.c:469
...
Reproduced starting from 76def4cdd.
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
5a1d51b9a1a7 in AbortTransaction () at xact.c:2853
#4 0x5a1d51b9abc6 in AbortCurrentTransactionInternal () at xact.c:3579
#5 AbortCurrentTransaction () at xact.c:3457
#6 0x5a1d51eafeda in PostgresMain (dbname=, username=0x5a1d75c139b8
"law") at postgres.c:4440
(gdb) p lockOwner
E ... RETURNING *) SELECT * FROM tmp ORDER BY ...
Thought?
Yeah, maybe such a trick will do.
23.03.2025 19:30, Melanie Plageman wrote:
On Sun, Mar 23, 2025 at 10:00 AM Alexander Lakhin wrote:
With autovacuum = off, all of these fluctuations go away.
If autovacuum is somehow corrupting the table, the
can't see "automatic vacuum/analyze" messages related
to ft2/ "S 1"."T 1", so autovacuum somehow affects contents of this table
indirectly.
With autovacuum = off, all of these fluctuations go away.
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=cul
s://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-03-17%2001%3A16%3A02
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
01' AND issue_link IS NULL; -- Unsorted/unhelpful failures
13
Short-lived failures:190
(I've also updated my script to exclude "*-build" failures.)
Best regards,
Alexander Lakhin
Neon (https://neon.tech)#!/bin/bash
TMP=${TMPDIR:-/tmp}
wget "https://bui
Hello Tom,
01.03.2025 20:04, Tom Lane wrote:
Alexander Lakhin writes:
It looks like 8f427187d broke pg_dump on Cygwin:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-02-26%2010%3A03%3A07
Yeah, Andrew and I have been puzzling over that off-list. pg_dum
..
if (errno)
{
/* On error, just return the error to the caller. */
return fresult;
}
else if ((*endptr == nptr) || isnan(fresult) ||
...
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
; END; $$ LANGUAGE
plpgsql STABLE;
SELECT min(id) OVER (PARTITION BY id ORDER BY id) FROM t WHERE id >=
stable_one();
ERROR: XX000: trying to open a pruned relation
LOCATION: ExecGetRangeTableRelation, execUtils.c:830
This issue was discovered with SQLsmith.
Best regards,
Alexander Lak
in standard_ExecutorStart (queryDesc=0x5a9b9fbb9970,
eflags=0) at execMain.c:268
#5 0x5a9b67e1a223 in ExecutorStart (queryDesc=0x5a9b9fbb9970, eflags=0) at
execMain.c:142
...
starting from cbc127917.
(I've discovered this anomaly with SQLsmith.)
Best regards,
Alexander Lakhin
Neo
y tests in
parallel and got failures on iterations 4, 14, 10.
But with PG_TEST_TIMEOUT_DEFAULT=190, 30 iterations passed for me (8 of
them took 180+ seconds).
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
OVER (PARTITION BY t.a)
FROM t AS t1 LEFT JOIN T ON true;
ERROR: XX000: wrong varnullingrels (b) (expected (b 3)) for Var 2/1
LOCATION: search_indexed_tlist_for_var, setrefs.c:2901
(I discovered this anomaly with SQLsmith.)
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
; s2_init' is a step for slot creation.
We can see that the isolation tester detects a process termination and exit.
Couldn't you suggest where to put, say, sleep(), to reproduce this failure
reliably?
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
d/unhelpful failures
18
Short-lived failures:
30
I've also offloaded past year's content of the "Known Buildfarm Test Failures"
page to:
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures_-_Archive
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
: XX000: tuple already updated by self
LOCATION: simple_heap_update, heapam.c:4374
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
_missing_activeslot_invalidation
There is also a reference to a discussion of the failure there:
https://www.postgresql.org/message-id/657815a2-5a89-fcc1-1c9d-d77a6986b...@gmail.com
(In short, I observed that that test suffers from bgwriter's activity.)
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
/wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures
[2]
https://www.postgresql.org/message-id/35d87371-f3ab-42c8-9aac-bb39ab5bd987%40gmail.com
Best regards,
Alexander Lakhin
Neon (https://neon.tech)
---
test: select_parallel
test: select_parallel
test: select_parallel
(e.g. with 100 repetitions)
Or
TESTS="test_setup copy create_misc create_index $(printf "select_parallel %.0s"
{1..100})" make check-tests
Best regards,
Alexander Lakhin
Neon (https://neo
Hello hackers,
I'd like to share my investigation of one mysterious stats.sql failure
occurred in December: [1].
The difference of the failure is:
--- C:/prog/bf/root/HEAD/pgsql/src/test/regress/expected/stats.out 2024-09-18
19:31:14.665516500 +
+++ C:/prog/bf/root/HEAD/pgsql.build/testrun/r
Hello hackers,
Please take a look at the December report on buildfarm failures:
# SELECT br, count(*) FROM failures WHERE dt >= '2024-12-01' AND
dt < '2025-01-01' GROUP BY br;
REL_13_STABLE: 6
REL_14_STABLE: 5
REL_15_STABLE: 4
REL_16_STABLE: 6
REL_17_STABLE: 13
master: 67
-- Total: 101
(Counting
Hello hackers,
03.09.2024 08:51, Michael Paquier wrote:
And done that.
Please look at another collection of typos and inconsistencies introduced
during 2024:
behvior -> behavior
contraint -> constraint
curent -> current
disable_node -> disabled_nodes
disabled_node > disabled_nodes
disable
Hello Tom,
16.12.2024 07:23, Tom Lane wrote:
Alexander Lakhin writes:
...
So GetSafeSnapshot() waits indefinitely for possibleUnsafeConflicts to
become empty (for other backend to remove itself from the list of possible
conflicts
inside ReleasePredicateLocks()), but it doesn't happen.
Hello David,
20.12.2024 12:31, David Rowley wrote:
The attcacheoff removal is now pushed. I've attached the two remaining patches.
Please look at the following query, which triggers (sometimes not on a
first run) an assert added with 5983a4cff:
regression=# SELECT COUNT(*) FROM
(SELECT (aclexp
Hello hackers,
I'd like to bring your attention to multiple buildfarm failures, which
occurred this month, on master only, caused by "could not open shared
memory segment ...: No such file or directory" errors.
First such errors were produced on 2024-12-16 by:
leafhopper
Amazon Linux 2023 | gcc
Hello Michael,
19.12.2024 06:21, Michael Paquier wrote:
Fixed that, bumped the two version counters, and done.
Could you, please, look at recent failures produced by grassquit (which
has fsync = on in it's config), on an added test case? For instance, [1]:
--- /home/bf/bf-build/grassquit/HEAD/
Hello hackers,
Investigating a recent buildfarm failure [1] with the following
diagnostics:
[12:27:41.437](0.024s) ok 18 - have walreceiver pid 637143
[12:30:42.564](181.127s) not ok 19 - walsender termination logged
[12:30:42.564](0.000s)
[12:30:42.564](0.000s) # Failed test 'walsender termina
Hello Heikki,
27.06.2024 21:35, Heikki Linnakangas wrote:
All I heard is crickets, so committed and backported to all supported versions.
Recently hornet made some noise too: [1], by failing on the test
modification added with e9c8747ee (in REL_13_STABLE):
# issuing query via background psql:
Hello hackers,
A recent buildfarm timeout failure on sawshark [1] made me wonder, what's
wrong with that animal — beside that failure, this animal (running on
OpenBSD 7.4) produced "too many clients" errors from time to time, e. g.,
[2], [3].
I deployed OpenBSD 7.4 locally and reproduced "too ma
Hello hackers,
A recent desman failure [1] with the following diagnostics:
# parallel group (2 tests): subscription publication
not ok 157 + publication 2251 ms
ok 158 + subscription 415 ms
--- /home/fedora/17-desman/buildroot/RE
02.12.2024 18:25, Tom Turelinckx wrote:
These crashes are hardly related to code changes, so maybe there are
platform-specific issues still...
I naively assumed that because llvm and clang are available in Trixie on
riscv64 that I could simply install them and enable --with-llvm on copperhead,
Hello Tom,
17.11.2024 20:28, Tom Turelinckx wrote:
I have now done just that, but on a new HiFive Premier P550 board [2]. It is
running Ubuntu 24.04 LTS with a board-specific kernel, currently
6.6.21-9-premier (2024-11-09). The buildfarm client is executing within a
Debian Trixie container cr
Hello hackers,
Please take a look at the November report on buildfarm failures:
# SELECT br, count(*) FROM failures WHERE dt >= '2024-11-01' AND
dt < '2024-12-01' GROUP BY br;
REL_12_STABLE: 8
REL_13_STABLE: 8
REL_14_STABLE: 13
REL_15_STABLE: 10
REL_16_STABLE: 37
REL_17_STABLE: 29
master: 42
--
Hello Alexander,
21.11.2024 09:34, Alexander Korotkov wrote:
I'm going to push this if no objections.
Please look at the following query, which triggers an error after ae4569161:
SET random_page_cost = 1;
CREATE TABLE tbl(u UUID);
CREATE INDEX idx ON tbl USING HASH (u);
SELECT COUNT(*) FROM tb
Hello hackers,
I'd like to bring your attention to an interesting failure produced by
caiman twice: [1] and [2].
As far as I can see, this animal runs on Fedora and gets OS updates on a
daily basis. At the moment of the first failure it had kernel:
6.12.0-0.rc6.20241108git906bd684e4b1.55.fc42.x8
Hello Tom and Andres,
17.11.2024 05:33, Tom Lane wrote:
Andres Freund writes:
Another failure in CI, that cleared up after a retry:
+WARNING: could not get result of cancel request due to timeout
Yeah. This has been happening off-and-on in the buildfarm ever
since we added that test. I'm
Hello hackers,
Please take a look at the October report on buildfarm failures:
# SELECT br, count(*) FROM failures WHERE dt >= '2024-10-01' AND
dt < '2024-11-01' GROUP BY br;
REL_12_STABLE: 9
REL_13_STABLE: 9
REL_14_STABLE: 19
REL_15_STABLE: 25
REL_16_STABLE: 12
REL_17_STABLE: 14
master: 109
--
Hello Noah,
31.10.2024 04:39, Noah Misch wrote:
I had pushed this during the indicated week, before your mail. Reverting it
is an option. Let's see if more opinions arrive.
I've accidentally discovered an incorrect behaviour caused by commit
4eac5a1fa. Running this script:
for ((j=1; j<=100;
28.10.2024 19:06, Tom Lane wrote:
I've also dumped buf in read_whole_file() and found that in both
PG_BINARY_R and "r" modes the 0d 0a ending is preserved. But it changed
to 0a with the "rt" mode (see [1]), and it makes the test (and the whole
`meson test`) pass for me.
Interesting. I believe w
Hello Tom,
27.10.2024 20:41, Tom Lane wrote:
I wrote:
In the no-good-deed-goes-unpunished department: buildfarm member
hamerkop doesn't like this patch [1]. The diffs look like
...
So what I'd like to do to fix this is to change
- if ((file = AllocateFile(filename, PG_BINARY_R)) == NULL)
Hello Jeff and Corey,
26.10.2024 01:18, Jeff Davis wrote:
On Tue, 2024-09-17 at 05:02 -0400, Corey Huinker wrote:
I've taken most of Jeff's work, reincorporated it into roughly the
same patch structure as before, and am posting it now.
I have committed the import side of this patch series; tha
Hello Noah,
27.10.2024 07:09, Noah Misch wrote:
On Sat, Oct 26, 2024 at 11:49:36AM -0700, Noah Misch wrote:
intra-grant-inplace-db.spec got a novel failure today:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sarus&dt=2024-10-26%2014%3A08%3A58
The isolationtester_waiting query is sup
Hello Alvaro and Tender Wang,
24.10.2024 17:00, Alexander Lakhin wrote:
Please look at a new anomaly introduced with 53af9491a. When running the
following script:
CREATE TABLE t (a int, b int, PRIMARY KEY (a, b));
CREATE TABLE pt (a int, b int, FOREIGN KEY (a, b) REFERENCES t(a, b))
PARTITION
Hello Alvaro,
22.10.2024 17:32, Alvaro Herrera wrote:
Yeah. I pushed these patches finally, thanks!
Please look at a new anomaly introduced with 53af9491a. When running the
following script:
CREATE TABLE t (a int, b int, PRIMARY KEY (a, b));
CREATE TABLE pt (a int, b int, FOREIGN KEY (a, b) R
1 - 100 of 604 matches
Mail list logo
