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
Hello Tatsuo-san,
11.10.2024 07:54, Tatsuo Ishii wrote:
...
- number of transactions actually pocessed: 1 (tps = 410.846343)
...
Patch pushed.
Please consider fixing a typo sneaked in that commit: pocessed -> processed?
Best regards,
Alexander
Hello Noah,
25.09.2024 01:43, Noah Misch wrote:
Pushed, but the pushes contained at least one defect:
Please look at an anomaly introduced with a07e03fd8.
With the attached modification for intra-grant-inplace.spec, running this
test triggers a Valgrind-detected error for me:
==00:00:00:09.62
Hello Tom,
16.10.2024 19:26, Tom Lane wrote:
Alexander Lakhin writes:
Maybe you would like to fix in passing several (not new) defects, I've
found while playing with ecpg under Valgrind:
Done. After evaluation I concluded that none of these were worth the
trouble to back-patch, but b
Hello Ranier,
16.10.2024 14:14, Ranier Vilela wrote:
Em qua., 16 de out. de 2024 às 04:45, Peter Eisentraut
escreveu:
This wouldn't fix anything, I think. If colors is NULL, then strsep()
already returns NULL, so the added code does nothing.
If *colors* is NULL, then the delimiter
Hello Tom,
14.10.2024 21:25, Tom Lane wrote:
Attached are rebased and renumbered 0006-0008, mostly to keep the
cfbot happy. We could actually stop here, if we were feeling lazy,
but now that I've done the work I'm inclined to push forward with
the rest.
The rest is just memory leak removal, an
Hello Peter,
11.09.2024 10:37, Peter Eisentraut wrote:
This has been committed.
I've discovered that starting from 0785d1b8b,
make check -C src/bin/pg_combinebackup
fails under Valgrind, with the following diagnostics:
2024-10-15 14:29:52.883 UTC [3338981] 002_compare_backups.pl STATEMENT:
Hello Ranier and Peter,
15.10.2024 14:44, Ranier Vilela wrote:
Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut
escreveu:
Thanks for the analysis. I think moreover we *only* need to check the
"stringp" for NULL, not the return value of strsep(), which would never
be NULL
Hello Richard and Tom,
04.09.2024 06:50, Richard Guo wrote:
I pushed this patch with the test case remaining, as it adds only a
minimal number of test cycles. I explained in the commit message why
the test case is included in equivclass.sql rather than in join.sql.
While playing with the equi
Hello Peter,
23.07.2024 15:38, Peter Eisentraut wrote:
This has been committed. Thanks.
Please look at the SCRAM secret, which breaks parse_scram_secret(),
perhaps because strsep() doesn't return NULL where strtok() did:
CREATE ROLE r PASSWORD
'SCRAM-SHA-256$4096:hpFyHTUsSWcR7O9P$LgZFIt6Oqd
Hello Masahiko-san,
01.12.2023 05:14, Masahiko Sawada wrote:
FYI I've configured the buildfarm animal perentie to run regression
tests including xid_wraparound:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=perentie&br=HEAD
Please look at a failure produced by perentie recently:
Hello Noah,
04.10.2024 21:57, Noah Misch wrote:
That makes sense. Would you file this at
https://github.com/cpan-authors/IPC-Run/issues? I suppose that code should
become roughly:
do { $r = POSIX::read(...) } while (!defined($r) && $!{EINTR});
croak ... unless defined($r);
Just for r
Hello Noah,
16.06.2024 02:48, Noah Misch wrote:
I don't see in https://github.com/cpan-authors/IPC-Run/issues anything
affecting PostgreSQL. If you know of IPC::Run defects, please report them.
If I knew of an IPC::Run defect affecting PostgreSQL, I likely would work on
it before absurdity like
Hello Michael,
02.10.2024 06:29, Michael Paquier wrote:
On Wed, Oct 02, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
Fortunately, it's still pretty warm here, so I'm wearing T-shirt and my
sleeve isn't long enough for that, but if you gave me 2-3 days, I would
focus on r
Hello Michael,
02.10.2024 03:52, Michael Paquier wrote:
Alexander, I've thought about a couple of fancy cases for
ExecutorRun() but I could not break it. Perhaps you have something in
your sleeve that would also break this case?
--
Fortunately, it's still pretty warm here, so I'm wearing T-sh
Hello Michael,
01.10.2024 05:07, Michael Paquier wrote:
On Mon, Sep 30, 2024 at 10:07:55AM +0900, Michael Paquier wrote:
...
And done this part.
If I'm not missing something, all the patches discussed here are committed
now, so maybe I've encountered a new anomaly.
Please try the following sc
Hello hackers,
Windows animal drongo reiterated a failure of 002_archiving_standby.pl [1]
recently [2] and this pushed me to run the issue to ground.
The log of the failed test contains:
[17:11:11.519](0.001s) ok 3 - recovery_end_command not executed yet
### Promoting node "standby"
# Running: p
Hello Tom and Jelte,
31.08.2024 07:04, Alexander Lakhin wrote:
I've tested your fix with the modification I proposed upthread:
idle_session_timeout_enabled = false;
}
+if (rand() % 10 == 0) pg_usleep(1);
/*
* (5) disable async signal conditions
Hello hackers,
Please take a look at the September report on buildfarm failures:
# SELECT br, count(*) FROM failures WHERE dt >= '2024-09-01' AND
dt < '2024-10-01' GROUP BY br;
REL_12_STABLE: 12
REL_13_STABLE: 11
REL_14_STABLE: 12
REL_15_STABLE: 22
REL_16_STABLE: 35
REL_17_STABLE: 19
master: 33
Hello Andrew and Thomas,
29.09.2024 18:47, Andrew Dunstan пишет:
I'm inclined to think we might need to reverse the order of the last two. TBH I don't really understand how this has
worked up to now.
I've looked at the last successful run [1] and discovered that
fe-secure-common.c didn't c
29.09.2024 18:47, Andrew Dunstan wrote:
Yeah, src/include/port/win32/sys/socket.h has:
#include
#include
#include
I'm inclined to think we might need to reverse the order of the last two. TBH I don't really understand how this has
worked up to now.
As far as I can see, in my
Hello Thomas and Andrew,
28.09.2024 23:52, Thomas Munro wrote:
On Sun, Sep 29, 2024 at 6:26 AM Andrew Dunstan wrote:
We should have included ws2tcpip.h, which includes this:
#define InetPtonA inet_pton
WINSOCK_API_LINKAGE INT WSAAPI InetPtonA(INT Family, LPCSTR pStringBuf, PVOID
pAddr);
It'
Hello Michael and Sami,
18.09.2024 08:46, Michael Paquier wrote:
So, I have applied 0001 down to 14, followed by 0002 on HEAD.
Please look at the script, which triggers Assert added by 24f520594:
(assuming shared_preload_libraries=pg_stat_statements)
SELECT repeat('x', 100) INTO t FROM genera
Hello Nathan,
20.09.2024 19:51, Nathan Bossart wrote:
Here's a (probably naive) attempt at fixing these, too. I'll give each
path a closer look once it feels like we've identified all the bugs.
Thank you for the updated patch!
I tested it with two code modifications (1st is to make each crea
Hello Nathan,
19.09.2024 21:36, Nathan Bossart wrote:
On Thu, Sep 19, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
completed with:
DROP INDEX CONCURRENTLY def_vec_quantizer_idx;
triggers an assertion failure:
TRAP: failed Assert("HaveRegisteredOrActiveSnapshot()&qu
Hello Nathan,
18.09.2024 22:52, Nathan Bossart wrote:
Committed. I waffled on whether to add a test for system indexes that used
pg_index's varlena columns, but I ended up leaving it out. I've attached
it here in case anyone thinks we should add it.
I've discovered that Jonathan's initial sc
Hello Tom and Nathan,
23.09.2023 21:00, Alexander Lakhin wrote:
23.09.2023 17:39, Tom Lane wrote:
I'm also now more than just slightly skeptical about whether
pg_database should have a toast table. Has anybody tried,
say, storing a daticurules field wide enough to end up
out-of-line?
S
Hello Michael and Anthonin,
22.08.2024 10:33, Michael Paquier wrote:
Looks OK to me. I have spent more time double-checking the whole, and
it looks like we're there, so applied. Now let's play with it in more
regression tests. Note that the refactoring patch has been merged
with the original
17.09.2024 10:47, Alexander Korotkov wrote:
Yes, now I did reproduce. I got that the problem could be that insert
LSN is not yet written at primary, thus wait_for_catchup doesn't wait
for it. I've workarounded that using pg_switch_wal(). The revised
patchset is attached.
Thank you for the re
Hi Alexander,
16.09.2024 21:55, Alexander Korotkov wrote:
Please find two patches attached. The first one does minor cleanup
including misuse of words you've pointed. The second one adds missing
wait_for_catchup(). That should fix the test failure you've spotted.
Please, check if it fixes an
Hello Thomas,
17.09.2024 04:01, Thomas Munro wrote:
On Mon, Sep 16, 2024 at 6:00 PM Alexander Lakhin wrote:
So this leak looks like a recent and still existing defect.
From my cartoon-like understanding of Windows, I would guess that if
event handles created by a program are leaked after it
Hello Thomas,
14.09.2024 23:32, Thomas Munro wrote:
On Sun, Sep 15, 2024 at 1:00 AM Alexander Lakhin wrote:
(That is, 0.1-0.2 MB leaks per one robocopy run.)
I observed this on Windows 10 (Version 10.0.19045.4780), with all updates
installed, but not on Windows Server 2016 (10.0.14393.0
Hello Andrew,
14.09.2024 17:22, Andrew Dunstan wrote:
On 2024-09-14 Sa 9:00 AM, Alexander Lakhin wrote:
While trying to reproduce inexplicable drongo failures (e. g., [1])
seemingly related to BackgroundPsql, I stumbled upon close, but not
the same issue. ...
Interesting, good detective
Hi Alexander,
10.08.2024 20:18, Alexander Korotkov wrote:
On Sat, Aug 10, 2024 at 7:33 PM Alexander Korotkov wrote:
On Tue, Aug 6, 2024 at 5:17 AM Alexander Korotkov wrote:
...
Here is a revised version of the patchset. I've fixed some typos,
identation, etc. I'm going to push this once it
07.09.2024 21:11, Noah Misch wrote:
Noah, what do you think of handling this error in line with handling of
ERROR_BROKEN_PIPE and ERROR_BAD_PIPE (which was done in 0ea1f2a3a)?
I tried the following change:
switch (GetLastError())
{
case ERROR_BROKEN_PIPE:
Hello hackers,
While trying to reproduce a recent fairywren (a Windows animal) failure,
I ran amcheck/amcheck/003_cic_2pc in parallel inside a slowed-down
VM and came across another issue:
### Stopping node "CIC_2PC_test" using mode fast
# Running: pg_ctl -D C:\src\postgresql\build/testrun/amchec
Hello Richard,
06.09.2024 12:51, Richard Guo wrote:
Ah I see. label_sort_with_costsize is only used to label the Sort
node nicely for EXPLAIN, and usually we do not display the cost
numbers in regression tests.
In fact, I see the error with the following (EXPLAIN-less) query:
create table t (
Hello Robert,
21.08.2024 17:29, Robert Haas wrote:
I went ahead and committed these patches. ...
Please take a look at the following code:
static void
label_sort_with_costsize(PlannerInfo *root, Sort *plan, double limit_tuples)
{
...
cost_sort(&sort_path, root, NIL,
lefttree-
1 - 100 of 567 matches
Mail list logo
