esulttype == BOOLOID);
+ }
```
--
Best regards,
Aleksander Alekseev
) was added in:
```
commit f727b63e810724c7187f38b2580b2915bdbc3c9c
Author: Tom Lane
Date: Fri Aug 29 15:43:34 2025 -0400
Provide error context when an error is thrown within WaitOnLock().
```
--
Best regards,
Aleksander Alekseev
From e98412e7b1133ece8c7003ee48c598fd27c8763f Mon Sep 17
Nikita
It's like "John". These entries don't seem to reference any particular person.
--
Best regards,
Aleksander Alekseev
't cause any performance
degradation for others, I don't see why it wouldn't be approved.
Unfortunately it's hard to tell more without any specific patch on
hands.
--
Best regards,
Aleksander Alekseev
he patch it would pass.
Yes, this is how we typically test cases like this. IMO adding a test
module would be helpful. It can be reused for other scenarios.
--
Best regards,
Aleksander Alekseev
not allow index-only scans.
Thanks for the patch.
Can you think of any test cases we can add to the code base?
--
Best regards,
Aleksander Alekseev
becomes
simpler (less if's, etc) and uses structures of smaller size. This is
probably not that important for the commit message. I removed it in
order to avoid confusion.
PFA patch v4.
--
Best regards,
Aleksander Alekseev
From fcb9de3f3d45f79a3a3ab920b5839a9394ece637 Mon Sep 17 00:00:00 2001
> 5.
> ```
> Datum
> bytea_sortsupport(PG_FUNCTION_ARGS)
> {
> SortSupport ssup = (SortSupport) PG_GETARG_POINTER(0);
> MemoryContext oldcontext;
> + ByteaSortSupport *bss;
> + bool abbreviate = ssup->abbreviate;
> ```
>
> The local variable “abbreviate” is only used once, do we really need to cache
> ssup->abbreviate into a local variable?
Agree, thanks.
--
Best regards,
Aleksander Alekseev
Hi John,
Thanks for the review.
> Don't these types disallow NUL bytes regardless of locale / character set?
You are right, they do. Here is the patch v3 with corrected comments.
--
Best regards,
Aleksander Alekseev
From f722f62073c232b9b928afd2797317a91369fc63 Mon Sep 17 00:00:00 2
e bottleneck is when you execute 10
queries CREATE INDEX on your particular database. There is a decent
chance that the actual bottleneck is far from the place you think it
might be (writing to the disk, as an example).
--
Best regards,
Aleksander Alekseev
Best regards,
Aleksander Alekseev
has low priority
since we are going to get rid of it in the near future, but Meson is
another matter.
--
Best regards,
Aleksander Alekseev
tests.
2. Suggestion: perhaps (entity)_(action) naming would be better, that
is: detoast_iterator_create(), detoast_iterator_free() etc.
3. If you could demonstrate that there is no performance degradation
for other scenarios that would be great.
--
Best regards,
Aleksander Alekseev
me too much - just wanted to share in case the
intent was to make the table screen-wide. It seems to be slightly
wider in practice.
--
Best regards,
Aleksander Alekseev
Hi,
> - Multi-tenant applications tracking per-query resource consumption (buffer
> hits/misses, CPU/IO time)
BTW speaking of buffer hits/misses, you can already do this with
EXPLAIN ANALYZE.
--
Best regards,
Aleksander Alekseev
ent the corresponding API and cover it with tests properly.
Perhaps we could include the corresponding extension to /contrib/, as
a reference implementation.
The advantage of this approach is that it decomposes the task into
separate steps each of which can be discussed, implemented, reviewed
and tested separately.
--
Best regards,
Aleksander Alekseev
Hi Jelte,
> FYI an equivalent page would be:
> https://commitfest.postgresql.org/me/?&author=-3
That's handy. Thanks for the tip!
Hi,
> > Isn't the cfbot.cputube.org web page obsolete now that we have the CI
> > status directly in the commitfest page?
>
> Well, yeah, it's kind of duplicative --- but it slices the data
> differently and it presents it differently. The more modern
> pages don't have an easily-bookmarked summa
ithout it.
*/
-/* #define USE_VALGRIND */
+#define USE_VALGRIND
/*
* Define this to cause pfree()'d memory to be cleared immediately, to
From 553d45826e1ec71ffd2a1d4bb4104d948cf8844d Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Wed, 13 Aug 2025 22:26:13 +0300
Subject:
Hi Tom,
> You didn't say what the test condition was, but from the patch
> I suppose it's a case where SelectConfigFiles is erroring out?
Steps to reproduce:
1. Uncomment USE_VALGRIND in src/include/pg_config_manual.h, then
rebuild and setup Postgres as usual
2. In the first terminal:
```
$ va
8d8e8d57fbb75b47458eee50d3161a94b4dffe85 Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Wed, 13 Aug 2025 22:26:13 +0300
Subject: [PATCH v1] Fix memory leaks in SelectConfigFiles()
Make sure the memory allocated by make_absolute_path() is freed when
SelectConfigFiles() fails. It's mainly to silence Valgrind
Hi,
I keep an eye on my patches using cfbog [1] and I think since recently
it started to mistakenly mark patches as "needs rebase" while in fact
everything is OK. If we take [2] for instance, it applies fine:
```
$ git am
~/Desktop/v4-0001-pgindent-improve-formatting-of-multiline-comments.patch
Hi,
> > The new status of this patch is: Ready for Committer
>
> Thanks for testing!
>
> Here is the rebased patch.
Rebased.
From 4d83acd61eee36784840e2d1228d0c854807bac0 Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Wed, 11 Sep 2024 13:17:33 +0300
Subject: [PATCH v
Hi Andrey,
> 0. checkpointer is going to flush a heap buffer but waits on content lock
> 1. client is resetting PD_ALL_VISIBLE from page
> 2. postmaster is killed and command client to go down
> 3. client calls LWLockReleaseAll() at ProcKill() (?)
> 4. checkpointer flushes buffer with reset PG_ALL
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
1 - 100 of 1005 matches
Mail list logo
