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
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
.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
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
course. If I read the current status of
January CF correctly this means sending 80 emails to an unknown number
of pgsql-hackers@ subscribers though.
--
Best regards,
Aleksander Alekseev
author is free to reopen the entry if he/she believes it was closed by
mistake.
I also agree that we should account for feature freezes.
--
Best regards,
Aleksander Alekseev
ls for this patch will get notified about
> that change.
> 5. If a patch is Ready for Committer and has a committer assigned,
> never add this label.
> 6. At the end of the commitfest, move all patches without that label.
> And close all patches with such a label.
Sounds perfect to me.
--
Best regards,
Aleksander Alekseev
t.
>
> They do -- we use them quite extensively nowadays.
Got it, thanks. I was a bit worried about Visual Studio in particular.
--
Best regards,
Aleksander Alekseev
port. Wouldn't it be simpler to pass the
callback straight to BootStrapSlruPage()?
After changing the patch accordingly it shouldn't move XactCtl and
others. This is just an irrelevant change.
--
Best regards,
Aleksander Alekseev
an entry by mistake few of the authors
have dozens of simultaneously open entries, so reopening an entry or
two several times a year doesn't take too much effort. In all other
respects the proposed approach is not worse than what we did until
now.
--
Best regards,
Aleksander Alekseev
uot;""
Ooops, never mind. The application asked me to log in and I didn't
notice that when I did it also moved the patch to the next CF. This
was the actual reason why I got an error.
Sorry for the noise.
--
Best regards,
Aleksander Alekseev
t mean going forward.
This doesn't work unfortunately.
When I try to move my patches from CF 2025-01 to CF 2025-03 I get an error:
"""
The status of this patch cannot be changed in this commitfest. You
must modify it in the one where it's open!
"""
--
Best regards,
Aleksander Alekseev
st. However
I'm not sure whether creating a new one, e.g.
ssl/t/004_code_coverage.pl will be much better considering the fact
that the test still has little (nothing) to do with SSL.
Personally I'm fine with either option though.
--
Best regards,
Aleksander Alekseev
ng anything quick and dirty anyway.
Did you consider checking if the referenced patchset addresses the
issue you described?
--
Best regards,
Aleksander Alekseev
; The result is the two's complement representation of the integer, with
> the most significant byte first.", and then list the examples to
> demonstrate that.
Thank you. Here is the corrected patch.
--
Best regards,
Aleksander Alekseev
From 731dadc5f87d4e62d4f064c7d0ce91bdbafd1888 M
it a bit and add
to the documentation?
--
Best regards,
Aleksander Alekseev
it I noticed the following comment:
```
-- check the conversion to/from text and set_netmask
```
Since we don't have set_netmask() I think the comment is wrong, so I
corrected it.
--
Best regards,
Aleksander Alekseev
From cd27cd694b53c4c8914ef9467a7af69de91017d5 Mon Sep 17 00:00:00 2001
From: Aleksander
ns, rather than integer operations (just as
> the bit <-> integer casts are documented in 9.6 "Bit String Functions
> and Operators").
Many thanks for your great feedback. Here is the corrected patch.
On Fri, Jan 17, 2025 at 7:29 PM Dean Rasheed
wrote:
> On Tue, 14 Jan 202
ad" the difference seems to be negligible - either way you crash.
Unless I'm missing something of course.
--
Best regards,
Aleksander Alekseev
of llast().
I'm not entirely sure. Although being a static inline function,
list_tail() is declared in a .h file. Removing it may break 3rd party
code.
Note that list_tail() and llast() don't do exactly the same.
list_tail() accepts NIL lists while llast() works only for non-NIL
lists.
Hi,
> Good catch. This comment is not 100% clear to me either.
> [...]
TWIMC zero-filling was added in 33cc5d8a4d0d (year 2001). The commit
doesn't reference the discussion behind this change and the comment
text hasn't changed since then.
--
Best regards,
Aleksander Alekseev
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.
--
Best regards,
Aleksander Alekseev
v3-0001
5Fo00QR7LNAcd1ZjgoBi4y97%2BK760YABs0vQHH5dLdkkMA%40mail.gmail.com
[2]: https://www.postgresql.org/docs/current/runtime-config-wal.html
--
Best regards,
Aleksander Alekseev
se make sure the patchset is registered on the
nearest open CF [1] This will ensure that the patchset is built on our
CI (aka cfbot [2]) and will not be lost.
[1]: https://commitfest.postgresql.org/
[2]: http://cfbot.cputube.org/
--
Best regards,
Aleksander Alekseev
select repeat('1', 50)::bit(50)::int;
> ERROR: integer out of range
Thanks. I agree that the proposed error messages look nicer than the
one I used in v6. Here is the corrected patch.
--
Best regards,
Aleksander Alekseev
From b9b5e358d00945bc0c4bb4a1b6e52497a6014690 Mon Sep 17 00:0
bytea out of valid range, ''..'\x'
... and also included tests for min/max integer values.
I discarded the 0002 patch that implemented get_bytes() / set_bytes().
This part doesn't seem to get much support, so let's focus on casting.
--
Best regards,
Aleksander Ale
and I expect it would
> break other people's applications too.
I think we need to introduce alternative data types e.g. datetime /
datetimetz pair if we want to do this.
--
Best regards,
Aleksander Alekseev
-bindir=/home/eax/pginstall-18/bin
--new-bindir=/home/eax/pginstall-18/bin
```
As always, your feedback and suggestions are most welcomed.
--
Best regards,
Aleksander Alekseev
v2-0001-Always-use-long-SLRU-segment-file-names.patch
Description: Binary data
Hi Michael,
> On Wed, Oct 09, 2024 at 05:39:22PM +0300, Aleksander Alekseev wrote:
> > Attached is a PoC patch that fixes this. There are some TODOs and
> > FIXMEs but all in all it works and passes the tests.
>
> The patch has exactly three TODOs, and it is kind of hard to f
e in slru.c without
introducing much performance overhead.
Also I'm going to submit precise steps to test this migration manually
for the reviewers convenience.
--
Best regards,
Aleksander Alekseev
ResultRelInfo) within a given PG major release branch which
turned out not to be the case. We will investigate whether it can be
easily fixed on TimescaleDB side.
--
Best regards,
Aleksander Alekseev
nusual code pattern" in the postgr.es/c/e54a42a sense.
Yes, this is another issue.
I'm working with the TimescaleDB dev team to fix these issues on the
TimescaleDB side.
--
Best regards,
Aleksander Alekseev
ire triggers */
ExecOpenIndices(resultRelInfo, false);
return resultRelInfo;
}
```
Where it's used from there is hard to track but it looks like this is
the reason why the new field ri_needLockTagTuple is not initialized.
I'll pass this piece of information to my colleagues.
--
Best regards,
Aleksander Alekseev
ple field for the
caller and it will contain garbage.
Since you assumed this is the correct usage, maybe it should?
--
Best regards,
Aleksander Alekseev
nd
others, one per node. It's going to be boilerplate for sure, but
considering the fact that we already generate some code I don't really
see drawbacks.
--
Best regards,
Aleksander Alekseev
NodeTag tag)
{
Node *result;
Assert(size >= sizeof(Node));/* need the tag, at least */
result = (Node *) palloc0(size);
result->type = tag;
return result;
}
#define makeNode(_type_)((_type_ *) newNode(sizeof(_type_),T_##_type_))
```
--
Best regards,
Aleksander Alekseev
lignment
is platform/compiler dependent too.
I guess we are going to need either a `pg_writecontoldata` tool or
`pg_controldata -w` flag. I wonder which option you find more
attractive, or maybe you have better ideas?
[1]: https://perldoc.perl.org/functions/pack
--
Best regards,
Aleksander Alekseev
caffeine in my blood is a bit low right now. I
suspect I may need to re-check this statement with a fresh head.
Also it occured to me that as a 4th option we could just get rid of
this check. Users however will pay the price every time they execute
pg_upgrade so I doubt we are going to do this.
, i.e:
```
if(new_cluster.controldata.cat_ver >= SLRU_SEG_FILENAMES_CHANGE_CAT_VER)
return;
```
--
Best regards,
Aleksander Alekseev
# Copyright (c) 2024, PostgreSQL Global Development Group
use strict;
use warnings FATAL => 'all';
use PostgreSQL::Test::Cluster;
use PostgreSQL:
ULL ESCAPE AS NULL. If there are no escape characters
and column delimiters (and no NULLs designations, and what else I
forgot) then your text file just contains one tuple per line.
--
Best regards,
Aleksander Alekseev
yntax such as LINES AS IS or
maybe COPY AS IS for convenience. Perhaps we should discuss it
separately though as a syntax sugar for a long list of options we
already support.
--
Best regards,
Aleksander Alekseev
y happy about breaking the existing behavior in
the discussed case. Not sure what the lesser evil would be - breaking
it or keeping it as is.
Some input from other people on the mailing list would be appreciated.
--
Best regards,
Aleksander Alekseev
oach would be
convenient for the author and the reviewers and also will allow us to
deliver value to the users sooner.
[1]:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=49d6c7d8daba
[2]: https://commitfest.postgresql.org/50/5277/
--
Best regards,
Aleksander Alekseev
Also I think it's more
> useful if it shares the same PRNG, controlled by setseed(), and it
> makes sense to group all such functions together.
Good point. Personally I don't have a strong opinion on whether
random_array() or array_random() is preferable, for me either option
is
rs, committers) feel otherwise.
--
Best regards,
Aleksander Alekseev
7;s used as a replica identity. Or
maybe even keep everything as is.
Thoughts?
--
Best regards,
Aleksander Alekseev
ls and also looked for other
comments like this. There seems to be only one call like this to fix.
--
Best regards,
Aleksander Alekseev
setof?
Any reason not to have an interface as simple and straightforward as
this:
```
=# SELECT array_random(1, 10, random(0, 3)) FROM generate_series( ... )
{5}
{1, 3, 8}
{7, 6}
...
```
? Or maybe I'm missing something?
--
Best regards,
Aleksander Alekseev
nt,
80::int) as arr;
This could be just a bike-shedding though. Does anyone feel necessary
to second any of these nitpicks?
[1]: https://www.postgresql.org/docs/current/functions-array.html
--
Best regards,
Aleksander Alekseev
Hi Michael,
> On Tue, Oct 29, 2024 at 03:23:15PM +0300, Aleksander Alekseev wrote:
> >> While unfortunately named, we cannot deprecate TRIM_ARRAY() because it
> >> is mandated by the standard.
> >
> > I didn't know that, thanks.
>
> Wow. Neither did
Hi everyone,
> I upgraded to Meson 1.6.0 and Lcov 2.0-1. Unfortunately it doesn't work:
> [...]
> I didn't investigate further.
Lcov 2.1 and 2.2beta don't work either.
--
Best regards,
Aleksander Alekseev
coverage.info
```
... I get:
```
...
Processing file src/pl/plpython/plpy_util.c
lines=33 hit=22 functions=4 hit=4 branches=14 hit=5
Processing file src/include/catalog/index.h
lines=10 hit=10 functions=2 hit=2
genhtml: ERROR: duplicate merge record src/include/catalog
```
I didn't investigate further.
--
Best regards,
Aleksander Alekseev
tch to ensure that the patch improves code coverage.
[1]: https://github.com/linux-test-project/lcov/releases/tag/v1.16
[2]:
https://postgr.es/m/CAJ7c6TN%2BMCh99EZ8YGhXZAdnqvNQYir6E34B_mmcB5KsxCB00A%40mail.gmail.com
--
Best regards,
Aleksander Alekseev
ent of your table. This being said, I didn't
investigate your scenario in much detail.
[1]:
https://www.postgresql.org/message-id/flat/CAJ7c6TPQJNFETz9H_qPpA3x7ybz2D1QMDtBku_iK33gT3UR34Q%40mail.gmail.com
--
Best regards,
Aleksander Alekseev
n 1.3.2. Although it's not ancient
(Feb 2024) there is 1.6.0 available. I'll try upgrading and let you
know the results.
--
Best regards,
Aleksander Alekseev
2ByWi%3DThKiOsnhqLpeTmctMrJWz3xRQobGSY6BA%40mail.gmail.com
--
Best regards,
Aleksander Alekseev
From e3a19689a335bf5c0c6aecd19e6fe3d17d456b2b Mon Sep 17 00:00:00 2001
From: Aleksander Alekseev
Date: Thu, 31 Oct 2024 17:54:56 +0300
Subject: [PATCH v1] Improve code coverage of network address functions
ct/lcov/releases/tag/v1.16
--
Best regards,
Aleksander Alekseev
x27;--show-details',
'--branch-coverage',
'/home/eax/projects/c/postgresql/build/meson-logs/coverage.info']'
returned non-zero exit status 1.
ninja: build stopped: subcommand failed.
```
I'm using Xubuntu 24.04 LTS and my lcov version is:
```
$ lcov --version
lcov: LCOV version 2.0-1
```
I tried using Autotools with the same results. Pretty confident it
worked before. I'm wondering if anyone else experienced this lately
and/or knows a workaround.
[1]: https://www.postgresql.org/docs/current/regress-coverage.html
--
Best regards,
Aleksander Alekseev
are
needed. I think you can just do:
```
+{ oid => '8811', descr => 'sort array',
+ proname => 'array_sort', prorettype => 'anyarray',
+ proargtypes => 'anyarray bool', prosrc => 'array_sort'}, <--
array_sort is used directly in `prosrc`
```
... unless I'm missing something.
--
Best regards,
Aleksander Alekseev
s likely) remove trim_array() and document this deviation from the
standard? Or at least document why it's named this way.
What do you think?
--
Best regards,
Aleksander Alekseev
s IMMUTABLE, so I believe this is fine. Similarly functions
dealing with timezones can return different results between the DBMS
restarts / updates, but we don't care and mark them IMMUTABLE anyway.
Otherwise we couldn't use these functions in functional indexes which
will make them rather useless.
--
Best regards,
Aleksander Alekseev
/5314/
--
Best regards,
Aleksander Alekseev
v1-0001-Rename-trim_array-to-array_trim.patch
Description: Binary data
1 - 100 of 919 matches
Mail list logo
