Re: [PATCH] pg_bsd_indent: improve formatting of multiline comments

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-

Re: [PATCH] pg_bsd_indent: improve formatting of multiline comments

: > /* > * 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

[PATCH] pg_bsd_indent: improve formatting of multiline comments

.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

Re: [PATCH] Split varlena.c into varlena.c and bytea.c

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

Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)

;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

Re: --enable-{debug,cassert} should also activate --enable-depend

ql.org/docs/release/16.0/ -- Best regards, Aleksander Alekseev

Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)

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

Re: --enable-{debug,cassert} should also activate --enable-depend

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

Re: Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)

adNailed() could be called for a non-existing relation. Wouldn't Assert() be more appropriate? -- Best regards, Aleksander Alekseev

Re: [PATCH] Remove unused #include's in src/backend/utils/adt/*

to me, let's keep . -- Best regards, Aleksander Alekseev v2-0001-Remove-unused-include-s-in-src-backend-utils-adt.patch Description: Binary data

[PATCH] Remove unused #include's in src/backend/utils/adt/*

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

Re: [PATCH] Split varlena.c into varlena.c and bytea.c

#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

Doc: section "8.21. Pseudo-Types" needs a bit of clarification?

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

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

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

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

all, this would be a poor design choice in my opinion. -- Best regards, Aleksander Alekseev

Re: Proposal: Make cfbot fail on patches not created by "git format-patch"

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

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

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

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

]: https://www.postgresql.org/docs/current/functions-aggregate.html -- Best regards, Aleksander Alekseev

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

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

Should we optimize the `ORDER BY random() LIMIT x` case?

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

Re: Proposal: Exploring LSM Tree‑Based Storage Engine for PostgreSQL (Inspired by MyRocks)

ome mature enough it can be discussed whether it's worth adding to /contrib/ or not. -- Best regards, Aleksander Alekseev

Re: strange perf regression with data checksums

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

Re: [PATCH] avoid double scanning in function byteain

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

Re: strange perf regression with data checksums

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

Re: [PATCH] oauth: Prevent stack overflow by limiting JSON parse depth

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

Re: Valgrind - showing memory leaks?

ld Postgres and run your tests again. Please let us know the results. -- Best regards, Aleksander Alekseev

Re: Review/Pull Request: Adding new CRC32C implementation for IBM S390X

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

Re: [PATCH] dynahash: add memory allocation failure check

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

Re: Fortify float4 and float8 regression tests by ordering test results

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

Re: Cygwin support

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

Re: someone else to do the list of acknowledgments

f >> you're interested or have questions. > > I am interested. +1 -- Best regards, Aleksander Alekseev

Re: Built-in Raft replication

not sure in which state Stolon is today. -- Best regards, Aleksander Alekseev

Re: Built-in Raft replication

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: Add pg_get_injection_points() for information of injection points

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

Re: doc patch: clarify the naming rule for injection_points

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

Re: New committer: Jacob Champion

> 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

Re: someone else to do the list of acknowledgments

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

Re: PostgreSQL 18 Release Management Team & Feature Freeze

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

Re: PostgreSQL 18 Release Management Team & Feature Freeze

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

Re: New criteria for autovacuum

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

Re: New criteria for autovacuum

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

Re: [PATCH] Refactor SLRU to always use long file names

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

Re: AIO v2.5

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

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

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

Re: [PATCH] Split varlena.c into varlena.c and bytea.c

> 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

Re: encode/decode support for base64url

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

[PATCH] Split varlena.c into varlena.c and bytea.c

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

Re: Patch: Cover POSITION(bytea,bytea) with tests

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

Re: ZStandard (with dictionaries) compression support for TOAST compression

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

Re: Proposal: manipulating pg_control file from Perl

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

Re: Proposal: manipulating pg_control file from Perl

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

Re: Proposal: manipulating pg_control file from Perl

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

Proposal: manipulating pg_control file from Perl

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

Re: [PATCH] Add reverse(bytea)

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

[PATCH] Add reverse(bytea)

://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

Re: encode/decode support for base64url

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

Re: Add arbitrary xid and mxid to pg_resetwal

resql.org/ -- Best regards, Aleksander Alekseev

Re: Trivial comment fix for tsquerysend()

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

Re: ZStandard (with dictionaries) compression support for TOAST compression

t regards, Aleksander Alekseev

Re: ZStandard (with dictionaries) compression support for TOAST compression

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

Re: Hook for Selectivity Estimation in Query Planning

willing to accept the proposed change considering its controversy. -- Best regards, Aleksander Alekseev

Re: Allow LISTEN on patterns

many people will agree. -- Best regards, Aleksander Alekseev

Re: Allow database owners to CREATE EVENT TRIGGER

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

Re: Hook for Selectivity Estimation in Query Planning

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

Re: is git.postgresql.org working fine?

1m51.879s sys0m26.096s $ git --version git version 2.48.1 ``` -- Best regards, Aleksander Alekseev

Patch: Cover POSITION(bytea,bytea) with tests

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

Script for determining code coverage of functions listed in pg_proc.dat

.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

Re: [PATCH] Refactor SLRU to always use long file names

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

Re: PATCH: warn about, and deprecate, clear text passwords

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

Re: new commitfest transition guidance

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

Re: new commitfest transition guidance

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

Re: new commitfest transition guidance

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

Re: Elimination of the repetitive code at the SLRU bootstrap functions.

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

Re: Elimination of the repetitive code at the SLRU bootstrap functions.

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

Re: new commitfest transition guidance

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

Re: new commitfest transition guidance

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

Re: new commitfest transition guidance

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

Re: [PATCH] Improve code coverage of network address functions

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

Re: Quadratic planning time for ordered paths over partitioned tables

ng anything quick and dirty anyway. Did you consider checking if the referenced patchset addresses the issue you described? -- Best regards, Aleksander Alekseev

Re: [PATCH] Add get_bytes() and set_bytes() functions

; 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

Re: [PATCH] Add get_bytes() and set_bytes() functions

it a bit and add to the documentation? -- Best regards, Aleksander Alekseev

Re: [PATCH] Improve code coverage of network address functions

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

Re: [PATCH] Add get_bytes() and set_bytes() functions

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

Re: Purpose of wal_init_zero

ad" the difference seems to be negligible - either way you crash. Unless I'm missing something of course. -- Best regards, Aleksander Alekseev

Re: useless list_tail()?

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.

Re: Purpose of wal_init_zero

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

Re: [PATCH] Refactor SLRU to always use long file names

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

Re: Purpose of wal_init_zero

5Fo00QR7LNAcd1ZjgoBi4y97%2BK760YABs0vQHH5dLdkkMA%40mail.gmail.com [2]: https://www.postgresql.org/docs/current/runtime-config-wal.html -- Best regards, Aleksander Alekseev

Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py

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

Re: [PATCH] Add get_bytes() and set_bytes() functions

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

Re: [PATCH] Add get_bytes() and set_bytes() functions

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

Re: IANA timezone abbreviations versus timezone_abbreviations

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

Re: [PATCH] Refactor SLRU to always use long file names

-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

Re: [PATCH] Refactor bytea_sortsupport()

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

Re: [PATCH] Refactor SLRU to always use long file names

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

Re: Potential ABI breakage in upcoming minor releases

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

Re: Potential ABI breakage in upcoming minor releases

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

Re: Potential ABI breakage in upcoming minor releases

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

Re: Potential ABI breakage in upcoming minor releases

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

Re: Potential ABI breakage in upcoming minor releases

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

  1   2   3   4   5   6   7   8   9   10   >