Hi Andrey,
> the test passes because you moved injection point to a very safe position
> [...]
> I want to emphasize that it seems to me that position of injection point is
> not a hint, but rather coincidental.
Well, I wouldn't say that the test passes merely because the location
of the injecti
Hi,
> If my understanding is correct, we should make a WAL record with the
> XLH_LOCK_ALL_FROZEN_CLEARED flag *before* we modify the VM but within
> the same critical section [...]
>
> A draft patch is attached. It makes the test pass and doesn't seem to
> break any other tests.
>
> Thoughts?
In
> > This is a tricky bug. Do you also have a proposal of a particular fix?
>
> If my understanding is correct, we should make a WAL record with the
> XLH_LOCK_ALL_FROZEN_CLEARED flag *before* we modify the VM but within
> the same critical section (in order to avoid race conditions within
> the sam
Hi again,
> I meant instance, not backend. Sorry for confusion.
It looks like I completely misunderstood what START_CRIT_SECTION() /
END_CRIT_SECTION() are for here. Simply ignore this part :) Apologies
for the noise.
er.pm
index 35413f14019..e810f123f93 100644
--- a/src/test/perl/PostgreSQL/Test/Cluster.pm
+++ b/src/test/perl/PostgreSQL/Test/Cluster.pm
@@ -1191,6 +1191,46 @@ sub start
=pod
+=item $node->poll_start() => success_or_failure
+
+Polls start after kill9
+
+We may need retries to start a new
Hi Andrey,
> I was reviewing the patch about removing xl_heap_visible and found the VM\WAL
> machinery very interesting.
> At Yandex we had several incidents with corrupted VM and on pgconf.dev
> colleagues from AWS confirmed that they saw something similar too.
> So I toyed around and accidenta
message that I included to the patch.
>
> As always, your feedback is most appreciated.
cfbot indicates that v1 needs a rebase. Here is v2.
From 5ae3320497d27045b1f64be5508349e0afcc4e06 Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Wed, 2 Jul 2025 13:49:37 +0300
Subject
ent, giving its callers the possibility to
differentiate allocation failures vs valid cases where the caller is
giving a NULL value in input. The rest of the code is adapted to that.
Author: Evgeniy Gorbanev
Co-authored-by: Aleksander Alekseev
Reviewed-by: Álvaro Herrera
Reviewed-by: Me
Discussi
;
entry->execs = 0;
```
We know that ecpgQuery can't be NULL because we hash its value above.
Thus ecpg_strdup can fail only if strdup() fails.
From 7f9c42897bcc7032e4bfe4c6bb6bae7b3883e8ac Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Fri, 18 Jul 2025 14:50:36
this idea with minimal changes to the existing logic.
From ba5dcae9311270e37e6181f5de0bb439a1b5b55b Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Fri, 11 Jul 2025 17:59:50 +0300
Subject: [PATCH v5 1/2] Add proper checks for ecpg_strdup() return value
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-
4e06 Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Thu, 26 Jun 2025 16:05:36 +0300
Subject: [PATCH v4] Add tests for binaryheap.c
Test our heap implementation more thoroughly at the binaryheap API level.
Aleksander Alekseev, reviewed by Nathan Bossart
Discussion: https://postgr.es/
Hi Michael,
> depending on what's set in a URI. I think that we need to redesign a
> bit ecpg_strdup(), perhaps by providing an extra input argument so as
> we can detect hard failures on OOM and let ECPGconnect() return early
> if we find a problem.
Makes sense. In this case however I believe w
Hi,
> > It seems like cfbot.cputube.org started to miss a *few* entries since
> > CF started. Does it have anything to do with the CF application
> > update?
>
> That's fixed now.
Many thanks. I also noticed that cfbot doesn't show entries from the
*upcoming* commitfest. I believe it did before a
Hi Bruce,
> I was thinking about the name of our new PG 18 pg_overexplain extension.
> "Over-explain" has a negative connotation, like how can over-explaining
> something be useful? Do we want that as the name of this new extension?
I think it was an intended pun and to my ears it's sort of funn
Hi Alvaro,
> This looks super baroque. Why not simplify a bit instead? Maybe
> something like
>
> [...]
Fair point. Here is the corrected patch.
From 35cbf8fa22d0a1e9d1b46784a83adfdfd5c675fb Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Fri, 11 Jul 2025 17:59:50 +
ret = con;
> ```
>
> I was tired or something and didn't think of this trivial fix.
>
> As a side note it looks like ecpg could use some refactoring, but this
> is subject for another patch IMO.
Forgot the attachment. Sorry for the noise.
From 0ef7a6ba96dd
Hi,
> While working on it I noticed a potentially problematic strcmp call,
> marked with XXX in the patch. I didn't address this issue in v2.
Here is the corrected patch v3. Changes since v2:
```
for (con = all_connections; con != NULL; con = con->next)
{
-
Hi Michael,
> Should we actually check sqlca_t more seriously if failing one of the
> strdup calls used for the port, host, etc. when attempting the
> connection? The ecpg_log() assumes that a NULL value equals a
> , which would be wrong if we failed one of these allocations
> on OOM.
If I read
Hi Nathan,
> I just noticed $SUBJECT. This seems to be an oversight in commit 2fc7af5,
> which simultaneously combined ckptXidEpoch and ckptXid into ckptFullXid
and
> removed the only use of that information, i.e., GetNextXidAndEpoch(). Any
> objections if I remove it now?
Good catch. I don't s
ue in v2.
Thoughts?
From 4af966774361eac189e011d92e985883ee03ee5a Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Fri, 11 Jul 2025 17:59:50 +0300
Subject: [PATCH v2] Add proper checks for ecpg_strdup() return value
Evgeniy Gorbanev, Aleksander Alekseev. Reviewed by TODO FIXME.
---
src/interfaces/ec
Hi Florents,
Thanks for the update!
> here's a v4 patch set
>
> - Extracted pg_base64_{en,de}_internal with an additional bool url param, to
> be used by other functions
> - Added a few more test cases
>
> Cary mentioned above
>
> > In addition, you may also want to add the C versions of base64
Hi,
> it seems not trivial to wrap up all the generated random values into a
> specific
> multi-dimensional array (more than 2 dimensions).
> for example, say we generated 24 random values and wanted to arrange them
> into a
> 3-dimensional array with shape [4, 3, 2].
> we can easily use:
> SELE
nchronously()).
Any chance we should call pgstat_report_wait_start(wait_event_info)
instead similarly to other functions in fd.c?
--
Best regards,
Aleksander Alekseev
--
Best regards,
Aleksander Alekseev
From 768fefc8d0ca29787d55c9c1163d736b662cdcd1 Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Wed, 2 Jul 2025 13:49:37 +0300
Subject: [PATCH v1] Refactor bytea_sortsupport()
Previously bytea_sortsupport() was implemented as a wrapper function for
* entries since
CF started. Does it have anything to do with the CF application
update?
--
Best regards,
Aleksander Alekseev
e sense. Here is the corrected patch.
--
Best regards,
Aleksander Alekseev
v2-0001-Add-tests-for-binaryheap.c.patch
Description: Binary data
Hi,
The proposed patch adds tests for binaryheap.c. This is similar to our
tests for RB-trees in test_rbtree.c.
--
Best regards,
Aleksander Alekseev
v1-0001-Add-tests-for-binaryheap.c.patch
Description: Binary data
e support.
The problem with the current text is that it implies that the protocol
version can only be 3.0 (=196608) which is wrong.
--
Best regards,
Aleksander Alekseev
Hi,
I noticed several places where we access `struct binaryheap` directly
instead of using binaryheap_size() and binaryheap_empty() which
doesn't seem right. Here is the patch.
--
Best regards,
Aleksander Alekseev
v1-0001-Use-binaryheap_-macro-where-appropriate.patch
Description: Binary data
t; I had changed a field name to from "isopen" to "is_open" and forgot to
> change the usage in that template. Very annoying that django templates
> not complaining about missing attributes...
Time to rewrite CF application in Haskell and Yesod? :D (Not
realistic, I know...)
--
Best regards,
Aleksander Alekseev
Hi,
> These files were moved to src/backend/lib
That is - src/common. Sorry for the confusion.
--
Best regards,
Aleksander Alekseev
e thus I couldn't find it.
Many thanks.
--
Best regards,
Aleksander Alekseev
Firstly, many thanks for working on this.
I don't see a button that would allow me to add a patch to PG19-1
(2025-07-01 - 2025-07-31). I tried to log out and log in but it didn't
change anything. Is it a bug or do I miss something?
--
Best regards,
Aleksander Alekseev
text and/or move
the pairing heap implementation closer to binary heap.
--
Best regards,
Aleksander Alekseev
v1-0001-Correct-src-backend-lib-README.patch
Description: Binary data
are right, these comments shouldn't have been changed. Apparently
the script is going to need slightly more complicated checks that I
initially thought.
Here is the corrected patch v4.
--
Best regards,
Aleksander Alekseev
v4-0001-pgindent-improve-formatting-of-multiline-comments.patch
Description: Binary data
ated patch.
I noticed a mistake in v2. Here is the corrected patch. Changes
comparing to the previous version:
```
-$lines[-1] =~ s!/(.+)\*/!/$1\n \*/!;
+$lines[-1] =~ s!(.+) \*/!$1\n \*/!;
```
--
Best regards,
Aleksander Alekseev
v3-0001-pgindent-improve-formatting-of-multiline-
:
> /*
> * This has to be bug-compatible with the original implementation, so
> * only encode 23 of the 24 bytes. :-) */
Thanks for the review. You are right, these comments shouldn't be affected.
It's going to be simpler to modify pgindent then. PFA the updated patch.
--
Best regards,
Aleksander Alekseev
v2-0001-pgindent-improve-formatting-of-multiline-comments.patch
Description: Binary data
.es/m/CAJ7c6TN7ppSmZMPejvKZreOs%3D%2BkJEhrGQNuVpmTjj9W-%3DMjgCg%40mail.gmail.com
--
Best regards,
Aleksander Alekseev
v1-0001-pg_bsd_indent-improve-formatting-of-multiline-com.patch
Description: Binary data
ffects so we will have to modify pg_bsd_indent a bit,
apparently somewhere here:
pr_commnet.c:
```
if (ps.col_1 && !format_col1_comments) {/* if comment starts in column
* 1 it should not be touched */
```
I will start a new thread and propose an appropri
;s shouldn't encounter this. Thus there is no
reason to break branch prediction for everyone here.
I agree with Tomas that adding Assert() in fact will not change much.
It can serve as a little piece of documentation maybe: "yes we thought
about it", that's all.
--
Best regards,
Aleksander Alekseev
ql.org/docs/release/16.0/
--
Best regards,
Aleksander Alekseev
Asserts() for cases that shouldn't happen in practice for
performance reasons. Since this code doesn't crash I suspect this is
one of such cases. Unless you are aware of a specific scenario that
makes the code crash of course.
--
Best regards,
Aleksander Alekseev
something about it. Autotools slowly approaches its end of life and
for Meson we don't seem to have an equivalent of --enable-depend. On
top of that I imagine how one could argue that these options should be
independent.
--
Best regards,
Aleksander Alekseev
adNailed() could be
called for a non-existing relation. Wouldn't Assert() be more
appropriate?
--
Best regards,
Aleksander Alekseev
to me, let's keep .
--
Best regards,
Aleksander Alekseev
v2-0001-Remove-unused-include-s-in-src-backend-utils-adt.patch
Description: Binary data
Hi,
clangd indicates that certain #include's are redundant. Removing them
will speed up the build process a bit.
--
Best regards,
Aleksander Alekseev
v1-0001-Remove-unused-include-s-in-src-backend-utils-adt.patch
Description: Binary data
#include "utils/varlena.h"
> +#include "varatt.h"
>
> Especially funcapi.h was apparently not used. The other additions are
> required includes that came previously via indirect includes.
Thanks, fixed. clangd complained that utils/fmgroids.h is not going to
be used, as it complained about funcapi.h before. So I choose not to
include fmgroids.h.
PFA patch v3.
--
Best regards,
Aleksander Alekseev
v3-0001-Split-varlena.c-into-varlena.c-and-bytea.c.patch
Description: Binary data
akes section 8.21 even more confusing is the fact that a little
below we say:
"""
cstring - Indicates that a function accepts or *returns* a
null-terminated C string
"""
Should we be slightly more precise here?
[1]: https://www.postgresql.org/docs/current/datatype-pseudo.html
[2]: https://www.postgresql.org/docs/current/functions-array.html
--
Best regards,
Aleksander Alekseev
servoir() is purely a figment of my imagination at the
moment. Semantically it does the same as array_sample(array_agg(t), N)
except the fact that array_sample(..., N) requires the array to have
at least N items. You can experiment with array_sample(array_agg(...),
N) as long as the subquery returns much more than N rows.
--
Best regards,
Aleksander Alekseev
all, this would be a poor design choice in my opinion.
--
Best regards,
Aleksander Alekseev
and provide at least a draft of the commit message,
because they know it's more convenient both for the reviewers (the
patch has better chances to be reviewed and tested), and for the
authors to rebase the patch after a while. Newcomers sometimes submit
patches that don't even target the `master` branch, and they don't
know we have cfbot.
--
Best regards,
Aleksander Alekseev
names
are going to be something like '???' or 'unnamed1'. I can imagine how
it could be convenient in more cases than just this one.
Any thoughts on whether we should support this?
[1]:
https://www.postgresql.org/message-id/flat/20160729141552.4062e19b%40fujitsu
--
Best regards,
Aleksander Alekseev
]: https://www.postgresql.org/docs/current/functions-aggregate.html
--
Best regards,
Aleksander Alekseev
ax
apparently is going to be mandatory. Otherwise we will have to check
"wait what if it's ORDER BY random() LIMIT?" for every single query. I
wonder what the community's opinion on having such a syntax is.
[1] e.g. https://samwho.dev/reservoir-sampling/
--
Best regards,
Aleksander Alekseev
TABLE ... AS SELECT * FROM tbl
TABLESAMPLE BERNOULLI(20)` but this is inconvenient and would be
suboptimal even if we supported global temporary tables.
1. Do you think there might be value in addressing this issue?
2. If yes, how would you suggest addressing it from the UI point of
view - by adding a special syntax, some sort of aggregate function, or
...?
--
Best regards,
Aleksander Alekseev
ome mature enough it
can be discussed whether it's worth adding to /contrib/ or not.
--
Best regards,
Aleksander Alekseev
hint bits are excluded from the equation. If memory
serves, VACUUM FULL and CHECKPOINT after filling the table and
creating the index should do the trick.
--
Best regards,
Aleksander Alekseev
ld be nice if you could prove that
your implementation is actually faster. I think something like a
simple micro-benchmark will do.
--
Best regards,
Aleksander Alekseev
is is a problem related exclusively to NUMA CPUs
with 90+ cores or I can reproduce it on SMT as well?
--
Best regards,
Aleksander Alekseev
ix (attached) can
> be pretty small.
>
> [...]
Thanks for the patch. It looks good to me. It's well documented and
covered with tests. I can confirm that the tests pass. Also they fail
if I decrease the $nesting_limit value to 15.
--
Best regards,
Aleksander Alekseev
ld Postgres and run your tests again. Please let us know the results.
--
Best regards,
Aleksander Alekseev
register it on the nearest open commitfest [1] so that it
wouldn't be lost.
I didn't review the patch but wanted to point out that when it comes
to performance improvements it's typically useful to provide some
benchmarks.
[1]: https://commitfest.postgresql.org/53/
--
Best regards,
Aleksander Alekseev
and can return a NULL pointer.
> Added the pointer check for avoiding a potential problem.
Thanks for the patch. It looks correct to me.
I didn't check if it needs to be back-ported and if it does - to how
many branches.
--
Best regards,
Aleksander Alekseev
h
> changes only regression tests, it's maybe also worth backpatching.
I don't see a reason for backpatching this but I'm not strongly
opposed to the idea either.
--
Best regards,
Aleksander Alekseev
ironment. I actually like the project but I wouldn't recommend
running Postgres on prod, and for development these days it's simpler
to use WSL / VirtualBox / Raspberry Pi, or running Postgres natively
on Windows.
--
Best regards,
Aleksander Alekseev
f
>> you're interested or have questions.
>
> I am interested.
+1
--
Best regards,
Aleksander Alekseev
not sure in which state Stolon is today.
--
Best regards,
Aleksander Alekseev
on't use Patroni/Stolon/CockroachDB/Neon/... already.
Although the idea is tempting personally I'm inclined to think that
it's better to invest community resources into something else.
--
Best regards,
Aleksander Alekseev
re gathered in injection_points extension so IMO
pg_get_injection_points() belongs there. It would be awkward to have
it in the core considering the fact that injection points presumably
should be disabled in release builds. Users will see a function in \df
that does nothing.
--
Best regards,
Aleksander Alekseev
ints like this:
``
AtEOXact_Inval-with-transInvalInfo
heap_update-before-pin
```
Otherwise we would contradict our own documentation.
I don't mind heap-update-before-pin, but not 100% sure if:
at-eo-xact-inval-with-trans-inval-info
... would be a better name than the current one.
--
Best regards,
Aleksander Alekseev
> The Core Team would like to extend our congratulations to Jacob
> Champion, who has accepted an invitation to become our newest PostgreSQL
> committer.
Congrats, Jacob!
--
Best regards,
Aleksander Alekseev
ink about this. Please discuss here if
> >> you're interested or have questions.
> >
> > I am interested.
>
> +1
Sorry, I've just realized that my +1 can be interpreted as both voting
for Corey and as volunteering for making the list of acknowledgments.
To clarify, I meant that I'm interested too :)
--
Best regards,
Aleksander Alekseev
burden either.
> >
> > [1]: https://commitfest.postgresql.org/patch/5250/
>
> I would consider that a feature, too late for v18. There's not
> particular benefit in getting it into v18 vs later.
It was worth a try :) Good to know then, I will move the CF entry to
the next commitfest. Thanks!
--
Best regards,
Aleksander Alekseev
7;s worth merging SLRU refactoring into PG18, or is
it considered a feature? [1] This is arguably not the top priority and
we could wait for another year but merging it now doesn't seem to be
too much of a burden either.
[1]: https://commitfest.postgresql.org/patch/5250/
--
Best regards,
Aleksander Alekseev
nothing in between these two lines.
To my humble knowledge, CHECKOINT shouldn't set hint bits and should
take that long. At this point I don't know what's going on.
This is `master` branch, b82e7eddb023.
--
Best regards,
Aleksander Alekseev
need to introduce some overhead
that will affect all the users (not to mention people maintaining the
code). This would be convenient for sure but I'm not entirely sure if
it's worth it.
Thoughts?
--
Best regards,
Aleksander Alekseev
Hi Rustam,
> Hi Aleksander,
> I have reviewed your patch. It looks good to me.
>
> Kindest regards.
> Rustam Allakov
>
> The new status of this patch is: Ready for Committer
Thanks for testing!
Here is the rebased patch.
--
Best regards,
Aleksander Alekseev
v5-0001
full picture of how AIO should be
used. Perhaps instead of referencing smgrstartreadv() it would be
better to provide a simple but complete example, one that opens a
binary file and reads 512 bytes from it by the given offset for
instance.
--
Best regards,
Aleksander Alekseev
d a complete HTML code coverage report
(~36 Mb) [1].
[1]:
https://drive.google.com/file/d/1breVpHapvJLtw8AlFAdXDAbK8ZZytY6v/view?usp=sharing
--
Best regards,
Aleksander Alekseev
> The proposed patch extracts the code dealing with bytea from varlena.c
> into a separate file, as proposed previously [1]. It merely changes
> the location of the existing functions. There are no other changes.
Rebased.
--
Best regards,
Aleksander Alek
ggest
removing it and testing corner cases for base64url instead, which is
missing at the moment. Particularly there should be tests for
encoding/decoding strings of 0/1/2/3/4 characters and making sure that
decode(encode(x)) = x, always. On top of that you should cover with
tests the cases of invalid output for decode().
--
Best regards,
Aleksander Alekseev
Hi,
The proposed patch extracts the code dealing with bytea from varlena.c
into a separate file, as proposed previously [1]. It merely changes
the location of the existing functions. There are no other changes.
[1]: http://postgr.es/m/Zy2UqcZS2XAXBibq%40paquier.xyz
--
Best regards,
Aleksander
the example from
> the docs [1].
> position('\x5678'::bytea in '\x1234567890'::bytea) → 3
Thanks.
Here is the corrected patch.
--
Best regards,
Aleksander Alekseev
v2-0001-Cover-POSITION-bytea-bytea-with-tests.patch
Description: Binary data
ly during
VACUUM. We also discussed a special syntax for the feature, besides
other things.
[1]:
https://www.postgresql.org/message-id/flat/CAJ7c6TOtAB0z1UrksvGTStNE-herK-43bj22%3D5xVBg7S4vr5rQ%40mail.gmail.com
--
Best regards,
Aleksander Alekseev
tached with a Postgres 17 data directory as the arguemnt, and it
> should show all the fields.
Oh that's neat. Thanks for sharing!
--
Best regards,
Aleksander Alekseev
Hi Christoph,
> Re: Aleksander Alekseev
> > 1) Provide a tool written in C that allows changing pg_control, e.g.
> > `pg_writecontoldata` or maybe a flat like `pg_controldata -w`.
>
> I thought we already had pg_resetwal for that.
That's a good point.
In the case I
tly this use case.
Thanks for your reply.
It is my understanding that Perl is not extremely aware of alignment.
For instance if I want to modify the checksum of the file and the
offset of the checksum is let's say 200 bytes on one platform, 204 on
another and 208 on a third, pack/unpack will not help me.
Or did I miss something?
--
Best regards,
Aleksander Alekseev
rated file, don't edit!
checksum=AABBCCDD
pg_conrol_version=1800
cat_version=202503131
... etc ...
```
In case (2) we may consider getting rid of the pg_controldata tool.
Thoughts?
[1]: https://www.postgresql.org/message-id/ZzVOTc3ZgPWfEQut%40paquier.xyz
--
Best regards,
Aleksander Alekseev
Nathan, Daniel,
> > We already have array_reverse() and text_reverse(), so I see no strong
> > reason against also having a bytea_reverse().
>
> +1
I also considered adding reverse(bit) however to my knowledge there is
no practical usage for it.
--
Best regards,
Aleksander Alekseev
://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=6da469badaff
--
Best regards,
Aleksander Alekseev
v1-0001-Add-reverse-bytea-function.patch
Description: Binary data
O it would be nice to have.
Would you like to submit such a patch or are you merely suggesting an
idea for others to implement?
--
Best regards,
Aleksander Alekseev
resql.org/
--
Best regards,
Aleksander Alekseev
Hi Emre,
> Patch is attached.
I looked very closely and failed to understand what this patch fixes /
improves exactly. Maybe you could elaborate a bit?
--
Best regards,
Aleksander Alekseev
t regards,
Aleksander Alekseev
this. See the
previous discussions.
[1]: https://github.com/afiskon/zson
[2]:
https://postgr.es/m/CAJ7c6TP3fCC9TNKJBQAcEf4c%3DL7XQZ7QvuUayLgjhNQMD_5M_A%40mail.gmail.com
[3]: https://postgr.es/m/224711f9-83b7-a307-b17f-4457ab73aa0a%40sigaev.ru
[4]:
https://postgr.es/m/CAJ7c6TPSN06C%2B5cYSkyLkQbwN1C%2BpUNGmx%2BVoGCA-SPLCszC8w%40mail.gmail.com
--
Best regards,
Aleksander Alekseev
willing to accept the proposed change considering its controversy.
--
Best regards,
Aleksander Alekseev
many people will agree.
--
Best regards,
Aleksander Alekseev
rigger that looks like a regular one but works differently depending
on who creates them. Also what will happen if I promote a user to a
superuser or vice versa? All this doesn't strike me as a great UI.
Maybe you could explain your particular use case?
--
Best regards,
Aleksander Alekseev
Postgres,
contribute it to the upstream so that anyone will benefit from it.
Personally I agree with the sentiment, thus -1.
--
Best regards,
Aleksander Alekseev
1m51.879s
sys0m26.096s
$ git --version
git version 2.48.1
```
--
Best regards,
Aleksander Alekseev
1 - 100 of 981 matches
Mail list logo
