Hello Amit and Noah,
24.05.2024 14:15, Amit Kapila wrote:
I feel it is a good idea to do something about this. It makes sense to
start with something simple and see how it works. I think this can
also help us whether we need to chase a particular BF failure
immediately after committing.
Hello,
24.05.2024 22:29, Tom Lane wrote:
The partition_split test has unstable results, as shown at [1].
I suggest adding "ORDER BY conname" to the two queries shown
to fail there. Better look at other queries in the test for
possible similar problems, too.
Yes, I've just reproduced it on an
Hello hackers,
I'd like to discuss ways to improve the buildfarm experience for anyone who
are interested in using information which buildfarm gives to us.
Unless I'm missing something, as of now there are no means to determine
whether some concrete failure is known/investigated or fixed, how
Hello,
30.11.2023 10:35, Masahiko Sawada wrote:
I've attached new version patches (0002 and 0003 are unchanged except
for the commit message). I'll push them, barring any objections.
Pushed.
I've discovered that the test 001_emergency_vacuum.pl can fail due to a
race condition. I can't
Hello Dagfinn,
Thank you for paying attention to it and improving the possible fix!
20.05.2024 23:39, Dagfinn Ilmari Mannsåker wrote:
Nice cleanup! Did you use some static analysis tool, or did look for
them manually?
I reviewed my collection of unica I gathered for several months, but had
Hello hackers,
Please look at a bunch of unused variables and a couple of other defects
I found in the perl code, maybe you'll find them worth fixing:
contrib/amcheck/t/001_verify_heapam.pl
$result # unused since introduction in 866e24d47
unused sub:
get_toast_for # not used since 860593ec3
Hello Bertrand,
15.05.2024 11:31, Bertrand Drouvot wrote:
On Wed, May 15, 2024 at 10:14:09AM +0900, Michael Paquier wrote:
+if (object_description)
+ereport(ERROR, errmsg("%s does not exist",
object_description));
+else
+ereport(ERROR,
Hello Erik,
18.05.2024 04:31, Erik Wienhold wrote:
On 2024-05-17 02:06 +0200, Michael Paquier wrote:
On Thu, May 16, 2024 at 08:41:11AM +0200, Peter Eisentraut wrote:
On this specific patch, maybe reword "parameter too large" to "parameter
number too large".
WFM here.
Done in v3.
Thank
Hello Thomas,
18.05.2024 07:47, Thomas Munro wrote:
After more debugging, we learned a lot more things...
1. That query produces spectacularly bad estimates, so we finish up
having to increase the number of buckets in a parallel hash join many
times. That is quite interesting, but unrelated
Hello,
I decided to compare v17 vs v16 performance (as I did the last year [1])
and discovered that v17 loses to v16 in the pg_tpcds (s64da_tpcds)
benchmark, query15 (and several others, but I focused on this one):
Best pg-src-master--.* worse than pg-src-16--.* by 52.2 percents (229.84 >
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
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
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
Hi Bertrand,
09.05.2024 15:20, Bertrand Drouvot wrote:
Oh I see, your test updates an existing dependency. v4 took care about brand new
dependencies creation (recordMultipleDependencies()) but forgot to take care
about changing an existing dependency (which is done in another code path:
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
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
Hello Dmitry and Alexander,
Please look at one more anomaly with temporary tables:
CREATE TEMP TABLE t (a int) PARTITION BY RANGE (a);
CREATE TEMP TABLE tp_0 PARTITION OF t FOR VALUES FROM (0) TO (1) ;
CREATE TEMP TABLE tp_1 PARTITION OF t FOR VALUES FROM (1) TO (2);
ALTER TABLE t MERGE
11.05.2024 07:25, Thomas Munro wrote:
On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin wrote:
11.05.2024 06:26, Thomas Munro wrote:
Perhaps a no-image, no-change registered buffer should not be
including an image, even for XLR_CHECK_CONSISTENCY? It's actually
useless for consistency checking
Hello Thomas and Andres,
Thank you for looking at this!
11.05.2024 06:26, Thomas Munro wrote:
On Sat, May 11, 2024 at 3:57 AM Andres Freund wrote:
On 2024-05-10 16:00:01 +0300, Alexander Lakhin wrote:
and discovered that XLogRecordAssemble() calculates CRC over a buffer,
that might
Hello hackers,
I've investigated a recent buildfarm failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dodo=2024-05-02%2006%3A40%3A36
where the test failed due to a CRC error:
2024-05-02 17:08:18.401 ACST [3406:7] LOG: incorrect resource manager data
checksum in record at
Hello hackers,
Looking at a recent failure on the buildfarm:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=morepork=2024-04-30%2020%3A48%3A34
# poll_query_until timed out executing this query:
# SELECT archived_count FROM pg_stat_archiver
# expecting this output:
# 1
# last actual
Hello hackers,
While trying to catch a sporadic regression test failure, I've discovered
that tests tsearch and advisory_lock in the parallel_schedule's group:
test: select_views ... tsearch ... advisory_lock indirect_toast equivclass
might fail, depending on timing, because the test
02.05.2024 19:21, Alvaro Herrera wrote:
Now, you could claim that the standard doesn't mention
INCLUDING/EXCLUDING CONSTRAINTS, therefore since we have come up with
its definition then we should make it affect not-null constraints.
However, there's also this note:
NOTE 520 — s, except for
Hello Alvaro,
01.05.2024 20:49, Alvaro Herrera wrote:
Here are two patches that I intend to push soon (hopefully tomorrow).
Thank you for fixing those issues!
Could you also clarify, please, how CREATE TABLE ... LIKE is expected to
work with NOT NULL constraints?
I wonder whether EXCLUDING
Hello,
28.04.2024 11:05, David Rowley wrote:
On Sat, 20 Apr 2024 at 16:09, David Rowley wrote:
Here are a few more to see if it motivates anyone else to do a more
thorough search for another batch.
I've pushed these now.
Please look also at the list of other typos and inconsistencies I've
30.04.2024 13:20, Alexander Korotkov wrote:
On Tue, Apr 30, 2024 at 9:00 AM Alexander Lakhin wrote:
I've discovered another failure, introduced by d3d55ce57.
Please try the following:
CREATE TABLE t (a int unique, b float);
SELECT * FROM t NATURAL JOIN LATERAL
(SELECT * FROM t t2
Hi Bertrand,
25.04.2024 10:20, Bertrand Drouvot wrote:
postgres=# CREATE FUNCTION f() RETURNS int LANGUAGE SQL RETURN f() + 1;
ERROR: cache lookup failed for function 16400
This stuff does appear before we get a chance to call the new
depLockAndCheckObject()
function.
I think this is what
Hello Alexander,
23.10.2023 12:47, Alexander Korotkov wrote:
I think this patch makes substantial improvement to query planning.
It has received plenty of reviews. The code is currently in quite
good shape. I didn't manage to find the cases when this optimization
causes significant overhead
30.04.2024 03:10, Dmitry Koval wrote:
Hi!
1.
29.04.2024 21:00, Alexander Lakhin wrote:
I still wonder, why that constraint (now with a less questionable name) is
created during MERGE?
The SPLIT/MERGE PARTITION(S) commands for creating partitions reuse the existing code of CREATE TABLE
Hi Dmitry,
19.04.2024 02:26, Dmitry Koval wrote:
18.04.2024 19:00, Alexander Lakhin wrote:
leaves a strange constraint:
\d+ t*
Table "public.tp_0"
...
Not-null constraints:
"merge-16385-26BCB0-tmp_i_not_null" NOT NULL "
Hello Tom and Michael,
29.04.2024 08:11, Tom Lane wrote:
Michael Paquier writes:
If you grep the source tree, you'd notice that a prepared transaction
named gxid only exists in the 2PC tests of ECPG, in
src/interfaces/ecpg/test/sql/twophase.pgc. So the origin of the
failure comes from a race
Hello Richard,
29.04.2024 04:12, Richard Guo wrote:
Does anyone have any clue to this failure?
FWIW, after another run of this test, the failure just disappears. Does
it suggest that the test case is flaky?
I think this could be caused by the ecpg test twophase executed
simultaneously with
Hello,
28.04.2024 03:59, Alexander Korotkov wrote:
The revised patchset is attached. I'm going to push it if there are
no objections.
I have one additional question regarding security, if you don't mind:
What permissions should a user have to perform split/merge?
When we deal with mixed
27.04.2024 18:00, Alexander Lakhin wrote:
Please look also at another script, which produces the same error:
I've discovered yet another problematic case:
CREATE TABLE tbl1 (a int GENERATED ALWAYS AS IDENTITY, b text)
PARTITION BY LIST (a);
CREATE TABLE tbl2 (b text, a int NOT NULL
Hello Ashutosh,
26.04.2024 21:00, Alexander Lakhin wrote:
26.04.2024 15:57, Ashutosh Bapat wrote:
Thanks Alexander for the report.
On Fri, Apr 26, 2024 at 5:30 PM Alexander Lakhin wrote:
CREATE TABLE tbl3 (LIKE tbl2 INCLUDING IDENTITY);
ERROR: no owned sequence found
Do you
26.04.2024 15:57, Ashutosh Bapat wrote:
Thanks Alexander for the report.
On Fri, Apr 26, 2024 at 5:30 PM Alexander Lakhin wrote:
CREATE TABLE tbl3 (LIKE tbl2 INCLUDING IDENTITY);
ERROR: no owned sequence found
I don't think creating a table like a partition is common or even
Hello Ashutosh and Peter,
16.01.2024 21:59, Peter Eisentraut wrote:
On 09.01.24 15:10, Ashutosh Bapat wrote:
Here's complete patch-set.
Looks good! Committed.
Please take a look at a new error case introduced by 699586315:
CREATE TABLE tbl1 (a int PRIMARY KEY GENERATED BY DEFAULT AS
Hi,
25.04.2024 08:00, Bertrand Drouvot wrote:
though concurrent create/drop operations can still produce
the "cache lookup failed" error, which is probably okay, except that it is
an INTERNAL_ERROR, which assumed to be not easily triggered by users.
I did not see any of those "cache lookup
24.04.2024 20:36, Alvaro Herrera wrote:
So I added a restriction that we only accept such a change when
recursively adding a constraint, or during binary upgrade. This should
limit the damage: you're no longer able to change an existing constraint
from NO INHERIT to YES INHERIT merely by doing
Hi Bertrand,
24.04.2024 11:38, Bertrand Drouvot wrote:
Please find attached v2 that should not produce the issue anymore (I launched a
lot of attempts without any issues). v1 was not strong enough as it was not
always checking for the dependent object existence. v2 now always checks if the
22.04.2024 13:52, Bertrand Drouvot wrote:
That's weird, I just launched it several times with the patch applied and I'm
not
able to see the seg fault (while I can see it constently failing on the master
branch).
Are you 100% sure you tested it against a binary with the patch applied?
Yes,
Hi Bertrand,
22.04.2024 11:45, Bertrand Drouvot wrote:
Hi,
This new thread is a follow-up of [1] and [2].
Problem description:
We have occasionally observed objects having an orphaned dependency, the
most common case we have seen is functions not linked to any namespaces.
...
Looking
Hello Peter,
07.04.2024 20:18, Peter Geoghegan wrote:
On Sun, Apr 7, 2024 at 1:00 PM Alexander Lakhin wrote:
SELECT * FROM t WHERE a < ANY (ARRAY[1]) AND b < ANY (ARRAY[1]);
TRAP: failed Assert("so->numArrayKeys"), File: "nbtutils.c", Line: 560, PID:
3251267
22.04.2024 00:49, Thomas Munro wrote:
On Mon, Apr 22, 2024 at 12:00 AM Alexander Lakhin wrote:
From what I can see, the following condition (namely, -l):
if ($path =~ /^pg_tblspc\/(\d+)$/ && -l "$backup_path/$path")
{
Hello Thomas and Robert,
20.04.2024 08:56, Thomas Munro wrote:
... it still broke[4]. So I'm not sure what's going on...
From what I can see, the following condition (namely, -l):
if ($path =~ /^pg_tblspc\/(\d+)$/ && -l "$backup_path/$path")
{
Hello hackers,
When playing with JSON_TABLE, I tried to replace tenk1 in regression tests
with a view based on JSON_TABLE, with the same content, and discovered
that for one sub-optimal query it's execution duration increased many-fold.
With the preparation script attached, I see the following
Hello Michael and Robert,
20.04.2024 05:57, Michael Paquier wrote:
On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote:
It looks to me like in the first run it took 3 minutes for the
replay_lsn to catch up to the desired value, and in the second run,
two seconds. I think I have seen
Hello,
30.01.2024 09:22, Ashutosh Bapat wrote:
Please look at the segmentation fault triggered by the following query since
4d969b2f8:
CREATE TABLE t1(a text COMPRESSION pglz);
CREATE TABLE t2(a text);
CREATE TABLE t3() INHERITS(t1, t2);
NOTICE: merging multiple inherited definitions of
18.04.2024 20:49, Alvaro Herrera wrote:
On 2024-Apr-18, Alexander Lakhin wrote:
I think the feature implementation should also provide tab completion
for SPLIT/MERGE.
I don't think that we should be imposing on feature authors or
committers the task of filling in tab-completion for whatever
Hello Alvaro,
18.04.2024 16:39, Alvaro Herrera wrote:
I have pushed a fix which should hopefully fix this problem
(d9f686a72e). Please give this a look. Thanks for reporting the issue.
Please look at an assertion failure, introduced with d9f686a72:
CREATE TABLE t(a int, NOT NULL a NO
Hi Alexander,
18.04.2024 13:35, Alexander Korotkov wrote:
The revised patchset is attached.
1) I've split the fix for the CommandCounterIncrement() issue and the
fix for relation persistence issue into a separate patch.
2) I've validated that the lock on the new partition is held in
Hello hackers,
When using a server built with clang (15, 18) with sanitizers enabled,
the last query in the following script:
SET parallel_setup_cost = 0;
SET min_parallel_table_scan_size = 0;
SELECT a::text INTO t FROM generate_series(1, 1000) a;
\timing on
SELECT string_agg(a, ',') FROM t
Hello Robert,
15.04.2024 17:30, Robert Haas wrote:
On Sat, Apr 13, 2024 at 6:05 AM Alexander Korotkov wrote:
Please, find a my version of this fix attached. I think we need to
check relpersistence in a similar way ATTACH PARTITION or CREATE TABLE
... PARTITION OF do. I'm going to polish
Hello Tomas,
14.04.2024 20:09, Tomas Vondra wrote:
I've pushed this, including backpatching the two fixes. I've reduced the
amount of data needed by the test, and made sure it works on 32-bits too
(I was a bit worried it might be sensitive to that, but that seems not
to be the case).
I've
Hi Dmitry,
12.04.2024 16:04, Dmitry Koval wrote:
Hi!
Attached is a patch with corrections based on comments in previous letters (I
think these corrections are not final).
I'll be very grateful for feedbacks and bug reports.
11.04.2024 20:00, Alexander Lakhin wrote:
> may be an atte
12.04.2024 08:05, Alexander Lakhin wrote:
2024-04-12 05:00:17.981 UTC [762336] PANIC: stuck spinlock detected at
WaitBufHdrUnlocked, bufmgr.c:5726
It looks like that spinlock issue caused by a race condition/deadlock.
What I see when the test fails is:
A client backend executing "
Hi Andres,
12.04.2024 07:41, Andres Freund wrote:
FWIW, I just reproduced the scenario with signals. I added tracking of the
total time actually slept and lost to SpinDelayStatus, and added a function to
trigger a wait on a spinlock.
To wait less, I set max_standby_streaming_delay=0.1, but
11.04.2024 16:27, Dmitry Koval wrote:
Added correction (and test), see
v3-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch.
Thank you for the correction, but may be an attempt to merge into implicit
pg_temp should fail just like CREATE TABLE ... PARTITION OF ... does?
Please
Hi Dmitry,
11.04.2024 11:59, Dmitry Koval wrote:
FWIW, I also proposed a patch earlier that fixes error messages and
comments in the split partition code
Sorry, I thought all the fixes you suggested were already included in v1-0002-Fixes-for-english-text.patch (but they
are not).
Added
10.04.2024 12:00, Alexander Lakhin wrote:
Hello Alexander and Dmitry,
10.04.2024 02:03, Alexander Korotkov wrote:
Thank you. I've pushed this fix with minor corrections from me.
Please look at another anomaly with MERGE.
CREATE TEMP TABLE t (i int) PARTITION BY RANGE (i);
CREATE TABLE
Hello Alexander and Dmitry,
10.04.2024 02:03, Alexander Korotkov wrote:
On Mon, Apr 8, 2024 at 11:43 PM Dmitry Koval wrote:
Attached fix for the problems found by Alexander Lakhin.
About grammar errors.
Unfortunately, I don't know English well.
Therefore, I plan (in the coming days) to show
08.04.2024 18:08, Tom Lane wrote:
Alexander Lakhin writes:
Now that ExecQueryUsingCursor() is gone, it's not clear, what does
the following comment mean:?
* We must turn off gexec_flag to avoid infinite recursion. Note that
* this allows ExecQueryUsingCursor to be applied
Hello Daniel and Tom,
08.04.2024 17:25, Daniel Verite wrote:
So I whacked the patch around till I liked it better, and pushed it.
Thanks for taking care of this!
Now that ExecQueryUsingCursor() is gone, it's not clear, what does
the following comment mean:?
* We must turn off gexec_flag
Hi Tender Wang,
08.04.2024 13:43, Tender Wang wrote:
Hi all,
I went through the MERGE/SPLIT partition codes today, thanks for the works.
I found some grammar errors:
i. in error messages(Users can see this grammar errors, not friendly).
ii. in codes comments
On a quick glance, I saw
Hello Jelte,
08.04.2024 11:36, Jelte Fennema-Nio wrote:
On Mon, 8 Apr 2024 at 10:00, Alexander Lakhin wrote:
As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
is fixed already.
Perhaps it's worth rechecking...
Using the attached script I got these timings. Clang
Hello Michael,
08.04.2024 08:23, Michael Paquier wrote:
On Fri, Apr 05, 2024 at 06:19:20PM +0200, Jelte Fennema-Nio wrote:
Agreed. While not a full solution, I think this patch is still good to
address some of the pain: Waiting 10 seconds at the end of my build
with only 1 of my 10 cores doing
08.04.2024 01:15, Alexander Korotkov wrote:
Thank you for spotting this. This seems like a missing check. I'm
going to get a closer look at this tomorrow.
Thanks!
There is also an anomaly with the MERGE command:
CREATE TABLE t1 (i int, a int, b int, c int) PARTITION BY RANGE (a, b);
CREATE
Hi Alexander and Dmitry,
07.04.2024 01:22, Alexander Korotkov wrote:
I've pushed 0001 and 0002. I didn't push 0003 for the following reasons.
Please try the following (erroneous) query:
CREATE TABLE t1(i int, t text) PARTITION BY LIST (t);
CREATE TABLE t1pa PARTITION OF t1 FOR VALUES IN
Hello Peter,
03.04.2024 22:53, Peter Geoghegan wrote:
On Mon, Apr 1, 2024 at 6:33 PM Peter Geoghegan wrote:
Note: v18 doesn't have any adjustments to the costing, as originally
planned. I'll probably need to post a revised patch with improved (or
at least polished) costing in the next few
05.04.2024 10:09, Amit Langote wrote:
Seems like it might be a pre-existing issue, because I can also
reproduce the crash with:
SELECT * FROM COALESCE(row(1)) AS (a int, b int);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while
Hello Amit,
04.04.2024 15:02, Amit Langote wrote:
Pushed after fixing these and a few other issues. I didn't include
the testing function you proposed in your other email. It sounds
useful for testing locally but will need some work before we can
include it in the tree.
I'll post the rebased
Hello Andres,
26.03.2024 10:59, Andres Freund wrote:
Late, will try to look more in the next few days.
AFAICS, last 027_streaming_regress.pl failures on calliphoridae,
culicidae, tamandua occurred before 2024-03-27:
Hello Alvaro,
27.02.2024 20:33, Alvaro Herrera wrote:
Here's the complete set, with these two names using the singular.
I've managed to trigger an assert added by 53c2a97a9.
Please try the following script against a server compiled with
-DTEST_SUMMARIZE_SERIAL (initially I observed this
Hello Alvaro,
28.03.2024 18:58, Alvaro Herrera wrote:
Grumble. I don't like initialization at declare time, so far from the
code that depends on the value. But the alternative would have been to
assign right where this blocks starts, an additional line. I pushed it
like you had it.
I've
Hello Tom,
29.03.2024 16:51, Tom Lane wrote:
Alexander Lakhin writes:
I think that deviation can be explained by the fact that cost_index() takes
baserel->allvisfrac (derived from pg_class.relallvisible) into account for
the index-only-scan case, and I see the following difference when a t
29.03.2024 11:59, Alexander Lakhin wrote:
But it looks like subselect is not the only test that can fail due to
vacuum instability. I see that create_index also suffers from cranky
ConditionalLockBufferForCleanup() (+if (rand() % 10 == 0)
return false; ), although it placed in parallel_schedule
29.03.2024 11:59, Alexander Lakhin wrote:
This simple change fixes the issue for me:
-VACUUM ANALYZE tenk2;
+VACUUM (ANALYZE, DISABLE_PAGE_SKIPPING) tenk2;
I'm sorry, I wasn't persevering enough when testing that...
After more test runs, I see that in fact it doesn't help.
Best regards
28.03.2024 20:33, Tom Lane wrote:
But I'm a bit confused - how come the estimates do change at all? The
analyze simply fetches 30k rows, and tenk only has 10k of them. So we
should have *exact* numbers, and it should be exactly the same for all
the analyze runs. So how come it changes like
Hello hackers,
When running multiple 027_stream_regress.pl test instances in parallel
(and with aggressive autovacuum) on a rather slow machine, I encountered
test failures due to the subselect test instability just as the following
failures on buildfarm:
1)
Hello David,
25.03.2024 04:43, David Rowley wrote:
I didn't see that as a reason not to push this patch as this occurs
both with and without this change, so I've now pushed this patch.
Please look at a new assertion failure, that is triggered by the following
query:
SELECT count(*) FROM (
Hello David,
23.01.2023 07:37, David Rowley wrote:
I've now pushed this.
I've discovered that the test query:
-- Ensure parallel aggregation is actually being used.
explain (costs off) select * from v_pagg_test order by y;
added by 16fd03e95 fails sometimes. For instance:
Hello Alvaro,
21.03.2024 15:07, Alvaro Herrera wrote:
Given that Michaël is temporarily gone, I propose to push the attached
tomorrow.
Please look at a new anomaly introduced with 374c7a229.
Starting from that commit, the following erroneous query:
CREATE FOREIGN TABLE fp PARTITION OF pg_am
Hello Jeff,
21.03.2024 03:13, Jeff Davis wrote:
On Tue, 2024-03-19 at 13:41 +0100, Peter Eisentraut wrote:
* v25-0002-Support-C.UTF-8-locale-in-the-new-builtin-collat.patch
Looks ok.
Committed.
Please look at a Valgrind-detected error caused by the following query
(starting from
Hello Melanie,
20.03.2024 16:15, Melanie Plageman wrote:
Seems like we could just add autovacuum_enabled=false to the table like this:
diff --git a/src/test/recovery/t/031_recovery_conflict.pl
b/src/test/recovery/t/031_recovery_conflict.pl
index d87efa823fd..65bc858c02d 100644
---
Hello hackers,
Among many recoveryCheck (more concretely, 027_stream_regress) failures
occurred on a number of buildfarm animals after switching to meson, which
can be explained by timeouts, I saw a different failure on adder:
14.03.2024 23:56, Tom Lane wrote:
Thomas Munro writes:
On Fri, Mar 15, 2024 at 7:00 AM Alexander Lakhin wrote:
Could it be that the timeout (360 sec?) is just not enough for the test
under the current (changed due to switch to meson) conditions?
But you're right that under meson the test
Hello Anton,
14.03.2024 23:36, Anton A. Melnikov wrote:
On 13.03.2024 10:41, Anton A. Melnikov wrote:
Here is a version updated for the current master.
During patch updating i mistakenly added double counting of deallocatated
blocks.
That's why the tests in the patch tester failed.
Fixed
Hello Thomas and Michael,
14.03.2024 06:16, Thomas Munro wrote:
Yeah, I was wondering if its checkpoint delaying logic might have
got the checkpointer jammed or something like that, but I don't
currently see how. Yeah, the replay of bulk newpages could be
relevant, but it's not exactly new
Hello David,
09.10.2023 07:13, David Rowley wrote:
On Mon, 9 Oct 2023 at 12:42, David Rowley wrote:
Maybe it's worth checking the total planning time spent in a run of
the regression tests with and without the patch to see how much
overhead it adds to the "average case".
I've now pushed the
Hello Bertrand and Michael,
12.03.2024 09:17, Bertrand Drouvot wrote:
May I
suggest the attached additions with LWLockHeldByMeInMode to make sure
that the stats are dropped and created while we hold
ReplicationSlotAllocationLock?
Yeah, makes fully sense and looks good to me.
Sorry for a
Hi,
13.07.2023 23:52, Andres Freund wrote:
Backpatching indeed was no fun. Not having BackgroundPsql.pm was the worst
part. But also a lot of other conflicts in tests... Took me 5-6 hours or
so.
But I now finally pushed the fixes. Hope the buildfarm agrees with it...
Thanks for the review!
Hello Nathan,
08.03.2024 01:00, Nathan Bossart wrote:
On Sun, Dec 10, 2023 at 12:00:01PM +0300, Alexander Lakhin wrote:
So I would not say that it's a dominant failure for now, and given that
04a09ee lives in master only, maybe we can save two commits (Revert +
Revert of revert) while moving
20.02.2024 07:57, Ashutosh Bapat wrote:
Could you please name functions, which you suspect, for me to recheck them?
Perhaps we should consider fixing all of such functions, in light of
b0f7dd915 and d57b7cc33...
Looks like the second commit has fixed all other places I knew except
Identity
Hello Ashutosh,
19.02.2024 15:17, Ashutosh Bapat wrote:
Functions ATExecAddIdentity() and ATExecDropIdentity() are recursive too,
so I think they can be exploited as well.
not just Identity related functions, but many other functions in
tablecmds.c have that problem as I mentioned earlier.
18.02.2024 19:18, Alexander Korotkov wrote:
Attached is a draft patch fixing this query. Could you, please, recheck?
Yes, this patch fixes the behavior for that query (I've also tried several
similar queries). Though I don't know the code well enough to judge the
code change.
Best regards,
Hi Alexander,
09.01.2024 01:09, Alexander Korotkov wrote:
Fixed in 30b4955a46.
Please look at the following query which fails with an error since
d3d55ce57:
create table t (i int primary key);
select t3.i from t t1
join t t2 on t1.i = t2.i,
lateral (select t1.i limit 1) t3;
ERROR:
Hello Ashutosh,
24.01.2024 09:34, Ashutosh Bapat wrote:
There's another thing I found. The file isn't using
check_stack_depth() in the function which traverse inheritance
hierarchies. This isn't just a problem of the identity related
function but most of the functions in that file. Do you
09.02.2024 21:59, Andres Freund wrote:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kestrel=2024-02-04%2001%3A53%3A44
) and saw that it's not checkpointer, but walsender is hanging:
How did you reproduce this?
As kestrel didn't produce this failure until recently, I supposed that
Hello Andres,
05.04.2023 21:48, Andres Freund wrote:
I just saw the following failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon=2023-04-05%2017%3A47%3A03
after a commit of mine. The symptoms look unrelated though.
[17:54:42.188](258.345s) # poll_query_until timed out
08.02.2024 12:25, vignesh C wrote:
Yes, the wakeup call sent by the "CREATE SUBSCRIPTION" command was
getting missed in this case. The wakeup call can be sent during
subscription creation/modification and when the apply worker exits.
WaitForReplicationWorkerAttach should not reset the latch here
1 - 100 of 372 matches
Mail list logo
