t regards,
Aleksander Alekseev
resql.org/
--
Best regards,
Aleksander Alekseev
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
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
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
://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
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
Hi,
This function is currently not covered by any tests. The proposed
patch fixes this.
--
Best regards,
Aleksander Alekseev
v1-0001-Cover-POSITION-bytea-bytea-with-tests.patch
Description: Binary data
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
willing to accept the proposed change considering its controversy.
--
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
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
many people will agree.
--
Best regards,
Aleksander Alekseev
stem, and I suspect very few users will voluntarily
trade convenience to security by choosing "disallow". So in its
current state the patch doesn't seem to help much.
--
Best regards,
Aleksander Alekseev
.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4f071349
[2]:
https://docs.google.com/spreadsheets/d/1i3_tfBjMO3QbnVVnWb1uwhp5R_gdmjdx1Q9eXmjoUUA/edit?usp=sharing
--
Best regards,
Aleksander Alekseev
coverage.csv.tgz
Description: GNU Zip compressed data
#!/usr/bin/env python3
# cov
Hi,
> > Here is an updated patch. The steps to test it manually are as follows.
> >
> > Compile and install PostgreSQL from the REL_17_STABLE branch:
> >
> > [...]
> >
> > As always, your feedback and suggestions are most welcomed.
>
> Rebased.
Reb
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
> 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
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
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
ome mature enough it
can be discussed whether it's worth adding to /contrib/ or not.
--
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
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
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
]: https://www.postgresql.org/docs/current/functions-aggregate.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
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
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
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
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
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
.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
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
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
#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
to me, let's keep .
--
Best regards,
Aleksander Alekseev
v2-0001-Remove-unused-include-s-in-src-backend-utils-adt.patch
Description: Binary data
ql.org/docs/release/16.0/
--
Best regards,
Aleksander Alekseev
;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
adNailed() could be
called for a non-existing relation. Wouldn't Assert() be more
appropriate?
--
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
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
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
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 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
e sense. Here is the corrected patch.
--
Best regards,
Aleksander Alekseev
v2-0001-Add-tests-for-binaryheap.c.patch
Description: Binary data
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 +
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/
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
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
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
e thus I couldn't find it.
Many thanks.
--
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
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
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
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
* entries since
CF started. Does it have anything to do with the CF application
update?
--
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
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,
> > 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 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
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,
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
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-
;
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
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
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
> > 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,
> 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
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
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 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.
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
901 - 981 of 981 matches
Mail list logo
