Re: The documentation for READ COMMITTED may be incomplete or wrong

to learn more about the internals of this part of the system and accompanying edge cases? Perhaps there is an experiment or two an extension author can do in order to lower the entry threshold and/or known bugs, limitations or wanted features one could start with? -- Best regards, Aleksander Alekseev

Re: "38.10.10. Shared Memory and LWLocks" may require a clarification

acing LWLock* in local process memory instead of shared memory is safe. Unless I missed something, I suggest updating the documentation and pg_stat_statements.c accordingly. [1]: https://github.com/afiskon/postgresql-extensions/blob/main/006-shared-memory/experiment.c#L38 -- Best regards, Aleksander Alekseev

Re: RFI: Extending the TOAST Pointer

(Something like "virtual methods" will produce a cleaner code but will also break branch prediction, so I don't think we should use those.) I don't think we need an example of adding a new TOAST tag in scope of this work since the default one is going to end up being such an example. Does it make sense? -- Best regards, Aleksander Alekseev

Re: "38.10.10. Shared Memory and LWLocks" may require a clarification

Hi, > Unless I missed something, I suggest updating the documentation and > pg_stat_statements.c accordingly. Since no one seems to object so far I prepared the patch. -- Best regards, Aleksander Alekseev v1-0001-Clarify-the-usage-of-shmem_startup_hook.patch Description: Binary data

Re: RFI: Extending the TOAST Pointer

0mail.gmail.com [2]: https://commitfest.postgresql.org/43/4296/ -- Best regards, Aleksander Alekseev

Re: "38.10.10. Shared Memory and LWLocks" may require a clarification

tat_statements/regress/log/postmaster.log -- Best regards, Aleksander Alekseev v2-0001-Clarify-the-usage-of-shmem_startup_hook.patch Description: Binary data

Re: "38.10.10. Shared Memory and LWLocks" may require a clarification

Hi hackers, That's me still talking to myself :) > Thoughts? Evidently this works differently from what I initially thought on Windows due to lack of fork() on this system. PFA the patch v3. Your feedback is most welcomed. -- Best regards, Aleksander Alekseev v3-0001-Clarify-the-

Re: ResourceOwner refactoring

Hi, > [...] > A-ha, it's because I didn't add the new test_resowner directory to the > src/test/modules/meson.build file. Fixed. > > Thanks for the review! You probably already noticed, but for the record: cfbot seems to be extremely unhappy with the patch. -- Best regards, Aleksander Alekseev

Re: Zstandard support for toast compression

e 18 is sizeof(varatt_external) + /* header size */ 2, which seems to be not extremely useful anyway. If you are interested in the topic please consider joining the thread. [1]: https://postgr.es/m/CAN-LCVMq2X%3Dfhx7KLxfeDyb3P%2BBXuCkHC0g%3D9GF%2BJD4izfVa0Q%40mail.gmail.com -- Best regards, Aleksander Alekseev

Re: [PATCH] Slight improvement of worker_spi.c example

he order of PushActiveSnapshot(...) and > SPI_connect() is not important. Additionally I noticed that the check: ``` if (!process_shared_preload_libraries_in_progress) return; ``` ... was misplaced in _PG_init(). Here is the patch v2 which fixes this too.

Re: [PATCH] Slight improvement of worker_spi.c example

Perhaps we should just say that the extension shouldn't be used without shared_preload_libraies. We are not testing whether it works in such a case anyway. -- Best regards, Aleksander Alekseev

Should "REGRESS_OPTS = --temp-config" be working for 3rd party extensions?

//github.com/afiskon/postgresql-extensions/tree/temp_config_experiment/007-gucs -- Best regards, Aleksander Alekseev

Re: [PATCH] Slight improvement of worker_spi.c example

going to be useful to make a complicated one out of it. The order of the calls it currently uses however may be extremely confusing for newcomers. It creates an impression that this particular order is extremely important while in fact it's not and it takes time to figure this out. -- Best regards, Aleksander Alekseev

Re: Should "REGRESS_OPTS = --temp-config" be working for 3rd party extensions?

e beforehand, or indeed rely on TAP > tests. Most projects properly setup their instance in the CI jobs, and at > least the Debian packaging infrastructure has a way to configure it too. Many thanks! -- Best regards, Aleksander Alekseev

Re: [PATCH] Slight improvement of worker_spi.c example

Hi Michael, Thanks for your feedback. > + * The order of PushActiveSnapshot() and SPI_connect() is not really > + * important. > > FWIW, looking at the patch, I don't think that this is particularly > useful. Fair enough, here is the corrected patch. -- Best

Re: [PATCH] Slight improvement of worker_spi.c example

ldn't the reverse ordering just give folks the opposite > impression? This is the exact reason why the original patch had an explicit comment that the ordering is not important in this case. It was argued however that the comment is redundant and thus it was removed. -- Best regards, Aleksander Alekseev

Re: Pluggable toaster

ps://www.postgresql.org/message-id/flat/CAM-w4HPjg7NwEWBtXn1empgAg3fqJHifHo_nhgqFWopiYaNxYg%40mail.gmail.com -- Best regards, Aleksander Alekseev

Re: [PATCH] Slight improvement of worker_spi.c example

liar with the problem in respect of naptime Julien is referring to. If you know what this problem is and how to fix it, go for it. I'll review and test the code then. I can write the part of the patch that fixes the part regarding dynamic workers if necessary. -- Best regards, Aleksander Alekseev

Re: Pluggable toaster

[1]: https://commitfest.postgresql.org/43/3626/ -- Best regards, Aleksander Alekseev

Re: Pluggable toaster

sider joining the compression > dictionaries effort instead [1]. During the discussion with the > community it ended up being a TOAST improvement after all. So we could > use your expertise in this area. > > [1]: https://commitfest.postgresql.org/43/3626/ -- Best regards, Aleksander Alekseev

Re: Add 64-bit XIDs into PostgreSQL 15

on how/what to proceed with. Yes, this thread awaits several other patches to be merged [1] in order to continue, so it makes sense to mark it as RwF for the time being. Thanks! [1]: https://commitfest.postgresql.org/43/3489/ -- Best regards, Aleksander Alekseev

Re: ResourceOwner refactoring

Hi, > Thanks, here's a fixed version. (ResourceOwner resource release > callbacks mustn't call ResourceOwnerForget anymore, but AbortBufferIO > was still doing that) I believe v15 is ready to be merged. I suggest we merge it early in the PG17 release cycle. -- Best regards, Aleksander Alekseev

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

racters. It is enough but also means + * that in the future we can't decrease SLRU_PAGES_PER_SEGMENT easily. + */ +return snprintf(path, MAXPGPATH, "%s/%015llX", ctl->Dir, (long long) segno); else return snprintf(path, MAXPGPATH, "

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

Hi, > On 19.08.24 16:10, Aleksander Alekseev wrote: > > To clarify, supporting bytea<->integer (and/or bytea<->numeric) casts > > doesn't strike me as a terrible idea but it doesn't address the issue > > I'm proposing to solve. > > What is the

Re: Add const qualifiers to XLogRegister*() functions

Hi, > On 04.10.23 16:37, Peter Eisentraut wrote: > > On 03.10.23 13:28, Aleksander Alekseev wrote: > >> While examining the code for similar places I noticed that the > >> following functions can also be const'ified: > > >> - XLogRegisterData (?) >

Re: Commit Timestamp and LSN Inversion issue

larly to INSERT INTO ... ON CONFLICT ... semantics, or similar approaches from long-lived and well-explored distributed system, e.g. Riak. Alternatively / additionally we could support CRDTs in Postgres. -- Best regards, Aleksander Alekseev

Re: Commit Timestamp and LSN Inversion issue

ties understanding why this is a problem and why it was necessary to mention CDR in this context in the first place. OK, let's forget about CDR completely. Who is affected by the current behavior and why would it be beneficial changing it? -- Best regards, Aleksander Alekseev

Re: [PATCH] Add roman support for to_number function

generate_series(1, 3999) AS i ) SELECT bool_and(to_number(roman, 'RN') = i) FROM rows; bool_and -- t ``` ... in order to fix this while on it. The query takes ~12 ms on my laptop. -- Best regards, Aleksander Alekseev

Re: Test improvements and minor code fixes for formatting.c.

Hi Tom, > Meh ... cfbot points out I did the float-to-int conversions wrong. > v2 attached. I'm having difficulties applying the patch. Could you please do `git format-patch` and resend it? -- Best regards, Aleksander Alekseev

[PATCH] Refactor SLRU to always use long file names

mplained). I didn't include any tests for the new pg_upgrade code. To my knowledge we test it manually, with buildfarm members and during alpha- and beta-testing periods. Please let me know if you think there should be a corresponding TAP test. Thoughts? -- Best regards, Aleksander Alekseev

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

Hi Michael, > On Wed, Sep 11, 2024 at 04:07:06PM +0300, Aleksander Alekseev wrote: > > Commit 4ed8f0913bfd introduced long SLRU file names. The proposed > > patch removes SlruCtl->long_segment_names flag and makes SLRU always > > use long file names. This simplifies b

Re: Add 64-bit XIDs into PostgreSQL 15

objects. We can always return to this later, preferably knowing that there is a particular committer who has time and energy for merging this. -- Best regards, Aleksander Alekseev

[PATCH] Support Int64 GUCs

ErvAD9vZYA%40mail.gmail.com -- Best regards, Aleksander Alekseev v1-0001-Support-64-bit-integer-GUCs.patch Description: Binary data

Re: Add 64-bit XIDs into PostgreSQL 15

s://commitfest.postgresql.org/50/5253/ -- Best regards, Aleksander Alekseev

Re: [PATCH] Support Int64 GUCs

?column? -- 123456 -- Best regards, Aleksander Alekseev

[PATCH] Refactor pqformat.{c,h} and protocol.h

e the code easier to read. [1]: https://www.postgresql.org/message-id/flat/1df84daa-7d0d-e8cc-4762-85523e45e5e7%40mailbox.org -- Best regards, Aleksander Alekseev v1-0001-Always-pass-PgMsg_-to-pg_beginmessage-_reuse.patch Description: Binary data v1-0002-Intoruce-PgMsg-enum.patch Descripti

Re: temp table on commit delete rows performance issue

etc. If you have indexes for a temporary table it makes the situation ever worse. Sooner or later VACUUM will happen for your bloated catalog, and this is not fun under heavy load. Is there any particular reason why you don't want to simply change the target table directly? If you do it in a transaction you are safe. -- Best regards, Aleksander Alekseev

Re: [PATCH] Refactor pqformat.{c,h} and protocol.h

Hi, > The proposed patchset fixes this. In v1 I mistakenly named the enum PgMsg while it should have been PqMsg. Here is the corrected patchset. -- Best regards, Aleksander Alekseev v2-0002-Introduce-PqMsg-enum.patch Description: Binary data v2-0001-Always-pass-PqMsg_-to-pq_beginmess

Re: [PATCH] Refactor pqformat.{c,h} and protocol.h

QcommMethods->putmessage() silently casts its first argument from `enum PqMsg` to `char` (shrug). -- Best regards, Aleksander Alekseev

Re: [PATCH] Refactor pqformat.{c,h} and protocol.h

ude this patch: > - Patch 3 rearranges the order of the functions in pqformat.{c,h} a > bit to make the code easier to read. ... since arguably there is not much value in it. Please let me know if you think it's actually needed. -- Best regards, Aleksander Alekseev v3-0001-Add-PqMsg_

Re: [PATCH] Refactor pqformat.{c,h} and protocol.h

Msg_Progress. I guess > PqMsg_ParallelProgress might be a tad more descriptive and less likely to > cause naming collisions with new frontend/backend messages, but I'm not > tremendously worried about either of those things. Thoughts? Personally I'm fine with either option. -- Best regards, Aleksander Alekseev

Re: Feature Request: Extending PostgreSQL's Identifier Length Limit

ml [2]: https://www.postgresql.org/docs/current/datatype-character.html -- Best regards, Aleksander Alekseev

[PATCH] Add crc32(text) & crc32(bytea)

og%40mail.gmail.com [2]: https://www.postgresql.org/message-id/flat/auto-000557707157%40umail.ru [3]: https://stackoverflow.com/questions/28179335/crc32-function-with-pl-pgsql [4]: https://gist.github.com/cuber/bcf0a3a96fc9a790d96d -- Best regards, Aleksander Alekseev v1-0001-Add-crc32-text-crc32-bytea.patch Description: Binary data

Re: July Commitfest: Entries Needing Review

now require actions from the author. If you are an author and you know that you are going to update the patch, consider changing its status to "Waiting on Author" for the time being. This will allow the reviewers to focus on patches that actually didn't get any attention so far. -- Best regards, Aleksander Alekseev

Re: Build with LTO / -flto on macOS

attention from the reviewers. Thus I changed the status of the CF entry to "Ready for Committer". -- Best regards, Aleksander Alekseev

Re: Build with LTO / -flto on macOS

if I understood it correctly, is merely to do on MacOS the same we currently do on Linux. -- Best regards, Aleksander Alekseev

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

code that uses SLRUs, and spotted three more > problematic code paths in predicate.c that needed an update like the > others for some pagenos. I've added these, and applied 0002. We > should be good now. Thank you! -- Best regards, Aleksander Alekseev

Re: Add new fielids only at last

Hi, > Currently, the new fields are only supported at the end, Cancannot move the > location of the field when editing the table, This does not seem to be an > elegant approach Pretty confident it was discussed many times before. Please use the search. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

, for clarity, but my plan is to merge both 0001 > and 0002 together. I reviewed and tested v6. I believe it's ready to be merged. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

would be crc32c() or crc32(x, version='c') or perhaps crc32(x, polinomial=...). I propose keeping the scope small this time. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

ten in hexadecimal. > > I'm not sure we should call the check values "hashes." Wikipedia does > include them in the "List of hash functions" page [0], but it seems to > deliberately avoid calling them hashes in the CRC page [1]. I'd suggest > calling them "

Re: Detach shared memory in Postmaster child if not needed

h. How do you estimate its performance impact? Note the comments for postmaster_child_launch(). This function is exposed to the third-party code and guarantees to attach shared memory. I doubt that there is much third-party code in existence to break but you should change to comment. -- Best regards, Aleksander Alekseev

Re: Is *fast* 32-bit support still important?

he performance of the upgrade procedure is probably not that important. The ability of processing a lot of data is probably also not extremely important, at least I wouldn't expect a lot of data and/or fast storage devices on 32-bit systems. -- Best regards, Aleksander Alekseev

Re: Is *fast* 32-bit support still important?

results you can't drop the support of 32-bit software (until it gets as difficult and pointless as with AIX that was dropped recently) and it will not tell you how slow the 32-bit version of PostgreSQL can be. If there are no actionable items why create a poll? -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

c > > Perhaps these would fit into src/backend/utils/hash/pg_crc.c? Thanks, PFA patch v3. -- Best regards, Aleksander Alekseev v3-0001-Add-crc32-bytea-crc32c-bytea.patch Description: Binary data

Re: Remove obsolete RECHECK keyword completely

, so this no > longer serves any need, it seems to me. > > This now removes it completely, and you'd get a normal parse error if > you used it. I reviewed and tested the code. LGTM. -- Best regards, Aleksander Alekseev

Re: meson "experimental"?

hich was about $SUBJECT.) Thanks. Re-attaching 0001 and adding it to the nearest CF to make it visible on cfbot. -- Best regards, Aleksander Alekseev v1-0001-Meson-is-not-experimental-on-Windows.patch Description: Binary data

Re: [PATCH] Add crc32(text) & crc32(bytea)

ere seems to be a demand [1][2] and it will allow us to easily cast a `bytea` value to `integer` or `bigint`. This is probably another topic though. [1]: https://stackoverflow.com/questions/32944267/postgresql-converting-bytea-to-bigint [2]: https://postgr.es/m/AANLkTikip9xs8iXc8e%2BMgz1T1701i

Re: Fsync (flush) all inserted WAL records

calls XLogBytePosToEndRecPtr() instead of XLogBytePosToRecPtr() inside it. > > Could you please advice which way to go? Does pg_current_wal_flush_lsn() [1] return what you need? [1]: https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-RECOVERY-CONTROL -- Best regards, Aleksander Alekseev

Re: Fsync (flush) all inserted WAL records

GetInsertRecPtr() and others. I believe you will find all you need for the task. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

OK, here is the corrected patch v4. -- Best regards, Aleksander Alekseev v4-0001-Add-crc32-bytea-crc32c-bytea.patch Description: Binary data

Re: Fsync (flush) all inserted WAL records

/or applied on a replica. Your case(s) however is different and I don't fully understand it. In any case you will need to implement an SQL-wrapper in order to make the function available to DBAs, cover it with tests and provide documentation. -- Best regards, Aleksander Alekseev

Re: Fsync (flush) all inserted WAL records

by users. Assuming the function has value, as you claim, I see no reason not to expose it similarly to pg_current_wal_*(). On top of that you will have to test-cover it anyway. The easiest way to do it will be to have an SQL-wrapper. -- Best regards, Aleksander Alekseev

Re: PostgreSQL's approach to assertion usage: seeking best practices

s usually a good idea unless the invariant is too expensive to check and/or complicated to read/understand. -- Best regards, Aleksander Alekseev

Re: format_datum debugging function

. Does it need a test? > Anything else? I think you forgot to attach the patch. Or is it just a proposal? -- Best regards, Aleksander Alekseev

Re: libpq minor TOCTOU violation

n() call. But it seems formally incorrect, so it seems good to > fix it, at least to make the code a better example. Not entirely sure about the presence of a serious security issue but silencing a static analyzer sounds like a good idea, especially since the fix is simple. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

Hi, > WFM. Here is what I have staged for commit. Patch v5 LGTM. -- Best regards, Aleksander Alekseev

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

67788 ``` Thoughts? [1]: https://postgr.es/m/CAJ7c6TNMTGnqnG%3DyXXUQh9E88JDckmR45H2Q%2B%3DucaCLMOW1QQw%40mail.gmail.com [2]: https://stackoverflow.com/questions/32944267/postgresql-converting-bytea-to-bigint [3]: https://postgr.es/m/AANLkTikip9xs8iXc8e%2BMgz1T1701i8Xk6QtbVB3KJQzX%40mail.gmail.com --

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

hose who want little-endian. However I want to propose them separately when we are done with this patch. -- Best regards, Aleksander Alekseev

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

u never know who uses Postgres and for what purpose. I will add corresponding casts unless the idea will get a push-back from the community. IMO the existence of these casts will at least not make things worse. -- Best regards, Aleksander Alekseev

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

comments on the patch. > > + * this routine treats "bytea" as an array of bytes. > > Maybe, the sentence should start with "This ... ". > > + while(size) > + { > > I wonder inserting a space after "while" is the standard s

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

integer (and/or bytea<->numeric) casts doesn't strike me as a terrible idea but it doesn't address the issue I'm proposing to solve. -- Best regards, Aleksander Alekseev

Re: [GSoC]The project summary

se how to use this plugin ( > https://github.com/charles-cui/pg_thrift/blob/master/README.md). > From this document, user knows how to install pg_thrift, how to parse out > required fields from byte using provided api, how to build index based on > the thrift bytes by the use of the api, and how to use the customized > thrift type. > -- Best regards, Aleksander Alekseev

Re: [GSoC]The project summary

e are no stupid mistakes that will blow up someone's PostgreSQL instance :) On Sun, Aug 5, 2018 at 11:04 PM, Aleksander Alekseev wrote: > Hello Charles, > > Thanks for keeping us informed. As you probably already discovered the > email I used previously doesn't work an

Re: GSoC 2018: thrift encoding format

Hello Charles, > Can I assume the data in thrift is always send inside a struct? Sure! > I think this question also valid for protobuf? Right, pg_protobuf assumes that data is always a message which is an equivalent of Thrift's struct. -- Best regards, Aleksander Alekseev si

Re: GSoC 2018: thrift encoding format

sonally I think raw data bytes are OK if functions for getting all keys and values from this data are provided. Another possibility is just converting Thrift to JSONB and vise versa. In this case only two procedures are required and all the rest is available out-of-the-box. -- Best regards, Alek

Re: GSoC 2018: thrift encoding format

->bytea all the time, and if we add implicit casting there will be little type safety left. In pg_protobuf extension I choose to store Protobuf as bytea, but if Charles prefer to introduce a separate type that's fine by me. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: GSoC 2018: thrift encoding format

Hello Vladimir, > I'm just trying to figure out what are the use cases for using that Thrift > extension. You can find an answer in the project description: https://wiki.postgresql.org/wiki/GSoC_2018#Thrift_datatype_support_.282018.29 -- Best regards, Aleksander Alekseev si

Re: GSoC 2018: thrift encoding format

ood point. > I understand that you're open to having it as a new data type or as a > bytea, but I don't agree. This should be a new data type, just as json > is a distinct data type and so is jsonb. Could you please explain in a little more detail why you believe so? Al

Re: [GSoC] github repo and initial work

Hello Charles, I suggest to begin with the second approach and add to_jsonb/from_jsonb later. Both approaches are fine but it seems to me that most users would expect a separate type thus it's more important. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

regarding encryption of the indexes since they will be encrypted on the block level the same way the heap will be. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: Jsonb transform for pl/python

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi Anthony, Thank you for the new version of the patch! Here

Re: Transform for pl/perl

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hello Anthony, Great patch! Everything is OK and I almost ag

Re: [HACKERS] Transform for pl/perl

obably in a separate patch. Thanks for the datasets though! -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: Jsonb transform for pl/python

tests of large numerics which weights quite heavy. So, > please find it in compressed format in attachments. I'm afraid that tests fail on Python 3: ``` SELECT test1set(); test1set --- ! "{None, 1, 'string'}" (1 row) DROP EXTENSION plpyt

Re: Transform for pl/perl

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Looks good to me. The new status of this patch is: Ready for

Re: new function for tsquery creartion

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi Victor, I like the idea and I think it's a great patch. H

Re: new function for tsquery creartion

ogle like syntax to create tsquery. ``` .. to something more like "provides a different syntax, similar to one used in web search engines, to create tsqeury". And maybe give a few examples right in the next sentence. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: GSoC 2018

-- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: GSoC 2018

be way to easy without implementing such tool. I changed the text on wiki, hopefully it's better now. [1]: https://github.com/afiskon/go-elector -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: GSoC 2018

erators like: ``` x -> 'field1' -- returns int x ->> 'field2' -- returns string ``` The reason why some users may prefer procedures to operators is that it's easy to make a typo in a field name. Procedures are safer in this regard. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: GSoC 2018

ly can't be a mentor for corresponding projects. Also today I'm going to contact Simone Gotti, the main developer of Stolon, to let him know about this thread. I wonder what are his thoughts on all this. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: Tracking of page changes for backup purposes. PTRACK [POC]

we clean up a bitmap, PTRACK says there are no changed pages", etc. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: Tracking of page changes for backup purposes. PTRACK [POC]

Hello Anastasia, > ptrack_9.6.6_v1.4.patch Also I'm surprised you proposed a patch for 9.6. Since PTRACK is a new feature I don't believe we are going to backport it. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: File name as application name in regression tests and elsewhere

gression suite. That should be > a pretty small patch and could be more generally useful. > > Thoughts? Personally, I see how it could be useful and don't see any drawbacks of such a patch. I think it's a good idea. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: Tracking of page changes for backup purposes. PTRACK [POC]

ytea * ptrack_get_and_clear(Oid tablespace_oid, Oid table_oid) { ``` Also I believe the patch should include some changes of postgresql.conf.sample. I suggest to add this patch to the closest commitfest. Otherwise it can be lost. -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: Tracking of page changes for backup purposes. PTRACK [POC]

5.441431 (excluding connections establishing) -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

[PATCH] Refactor bytea_sortsupport()

ena.c into varlena.c and bytea.c - also something proposed by Tom. IMO it would be a good move but this is not implemented in the patch. Thoughts? [1]: https://postgr.es/m/1502394.1725398354%40sss.pgh.pa.us -- Best regards, Aleksander Alekseev v1-0001-Refactor-bytea_sortsupport.patch Description: Binary data

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

essage. On the flip side the > situation when one wants something like extracting int4 from a > bytea(or vice versa) and is not happy with convenience and/or > performance of substr()+casts is arguably rare. I'll be fine with > whatever consensus the community reaches about this p

Re: [PATCH] Add min/max aggregate functions to BYTEA

se the patch and address the feedback received so far. PFA patch v6. -- Best regards, Aleksander Alekseev v6-0001-Add-min-and-max-aggregates-for-bytea-type.patch Description: Binary data

<    3   4   5   6   7   8   9   10   >