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
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
1 - 100 of 586 matches
Mail list logo
