Re: Shared detoast Datum proposal

- according to comments it could throw an OOM error, so I've changed it to HASH_ENTER_NULL to avoid new errors. In this case we would just have the value not cached without an error. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ 0001-toast

Re: Shared detoast Datum proposal

ded checks for if the value was stored or not. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

Hi, In addition to the previous message - for the toast_fetch_datum_slice the first (seems obvious) way is to detoast the whole value, save it to cache and get slices from it on demand. I have another one on my mind, but have to play with it first. -- Regards, Nikita Malakhov Postgres

Re: Shared detoast Datum proposal

user case of datum, > since we know the plan tree and knows the rows pass to a given node. > 2. Planning time effort is cheaper than run-time effort. > 3. eviction in my method is not as important as it is in TOAST cache > method since it is reset per slot, so usually it doesn't hit limit in > fact. But as a cache, it does. > 4. use up to memory limit we set in TOAST cache case. > > >>> In any case, my concern is more about having to do this when creating > >>> the plan at all, the code complexity etc. Not just because it might > have > >>> performance impact. > >> > >> I think the main trade-off is TOAST cache method is pretty non-invasive > >> but can't control the eviction well, the impacts includes: > >> 1. may evicting the datum we want and kept the datum we don't need. > > > > This applies to any eviction algorithm, not just LRU. Ultimately what > > matters is whether we have in the cache the most often used values, i.e. > > the hit ratio (perhaps in combination with how expensive detoasting that > > particular entry was). > > Correct, just that I am doubtful about design a LOCAL CACHE for USER > DATA with the reason I described above. > > At last, thanks for your attention, really appreciated about it! > > -- > Best Regards > Andy Fan > > > > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

and would report on the result here. There are also comments on the code itself, I'd write them a bit later. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

, it is a subject for a separate topic, as soon as I make it work on the current master we'll propose it to the community. Andy, thank you! I'll check the last patch set out and reply in a day or two. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

the whole value to be detoasted and kept in memory. What do you think? -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

atus of "Needs Review" [1], but it seems > > there were CFbot test failures last time it was run [2]. Please have a > > look and post an updated version if necessary. > > > > ====== > > [1] https://commitfest.postgresql.org/46/4456/ > > [2] https://cirrus-ci.com/task/5581154296791040 > > > > Kind Regards, > > Peter Smith. > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

le > TOAST? Maybe something we could add to src/test/modules similarly to > how we test SLRU, background workers, etc. > """ > > Since there was not much activity since then (for 3 months) I don't > really see how to process further. > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

or the whole session would immediately result in thousands of trace spans in the system with throughput like hundreds or even thousands of tps, when we need, say, to trace a single problematic query. Thank you! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: introduce dynamic shared memory registry

-load the extension? -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Is a clearer memory lifespan for outerTuple and innerTuple useful?

State. Since the code was writen by Tom at > 2005, so add Tom to the cc-list. > > > -- > Best Regards > Andy Fan > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

. It could be done by adding SQL function to add and remove query ID into a list (even array would do) stored in top tracing context. Great job, thank you! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: RFI: Extending the TOAST Pointer

. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ 0001_custom_toast_pointer_v1.patch Description: Binary data

Re: Avoid detoast overhead when possible

QUERY PLAN Seq Scan on b (cost=0.00..19.51 rows=1001 width=32) (actual time=0.159..62.807 rows=1001 loops=1) Planning Time: 0.033 ms Execution Time: 62.879 ms (3 rows)

Re: Avoid detoast overhead when possible

ory or existing-slot-in-place for > different sistuation, that would requires more expr expression changes > and planner changes. I just checked all the queries in my hand, the > current design can cover all of them. > > -- > Best Regards > Andy Fan > > > > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Avoid detoast overhead when possible

Hi! There's a view from the other angle - detoast just attributes that are needed (partial detoast), with optimized storage mechanics for JSONb. I'm preparing a patch for it, so maybe the best results could be acquired by combining these two techniques. What do you think? -- Regards, Nikita

Re: [Proposal] global sequence implemented by snowflake ID

; (snowflake IDs guarantee unicity with their machine ID), replication > may not be necessary because the sequence implementation may be able > to ensure that no replication is required from the start. > -- > Michael > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Table AM Interface Enhancements

suggest adding Assert(rel->rd_amcache == NULL) (or maybe better an > error report) after calling free_rd_amcache to be sure the custom > implementation has done what it should do. > > Also, I think some brief documentation about writing this custom method is > quite relevant maybe based

Re: Patch: Global Unique Index

Hi! Please advise on the status of this patch set - are there any improvements? Is there any work going on? Thanks! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: RFC: Pluggable TOAST

. Or should not? -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: RFC: Pluggable TOAST

ions that can then be used by >type-specific toast support functions. >Note that this would be opt-in for a type, thus all functions that use >that type's internals should be aware of the different on-disk format >for toasted values and should thus be able to handle it gracefully. Tha

Re: remaining sql/json patches

r example, >needing a catversion bump every time we convert one more function, >or an extension version bump to convert extensions.) so should figure out another way to do it. Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi! According to the discussion above, I've added the 'proerrsafe' attribute to the PG_PROC relation. The same was done some time ago by Nikita Glukhov but this part was reverted. This is a WIP patch, I am new to this part of Postgres, so please correct me if I'm going the wrong way. -- Nikita

Re: RFC: Pluggable TOAST

to rethink our approach to the TOAST enhancements according to it. Thanks a lot! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi, Agreed on the latter, that must not be the part of it for sure. Would think on how to make this part correct. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: RFC: Pluggable TOAST

enhancements we already have. Previous topic was not of any help here. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi, The main goal was to correctly process invalid queries (as in examples above). I'm not sure this could be done in type input functions. I thought that some coercions could be checked before evaluating expressions for saving reasons. -- Regards, Nikita Malakhov Postgres Professional

Re: RFC: Pluggable TOAST

large JSON objects. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

eval->jcstate->coercion && > + (post_eval->jcstate->coercion->via_io || > + post_eval->jcstate->coercion->via_populate)) > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

RFC: Pluggable TOAST

://www.postgresql.org/message-id/flat/CAN-LCVMq2X%3Dfhx7KLxfeDyb3P%2BBXuCkHC0g%3D9GF%2BJD4izfVa0Q%40mail.gmail.com -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

Hi, Thank you very much, I'll check it out. It looks like the getObjectIdentity() used in pg_identify_object() could do. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi, Sorry, forgot to mention above - patches from our patch set should be applied onto SQL/JSON part 3 - v22-0003-SQL-JSON-query-functions.patch, thus they are numbered as v23-0003-1 and -2. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

server was lost. Attempting reset: Failed. The connection to the server was lost. Attempting reset: Failed. Time: 6.858 ms @!> We're currently looking into this case. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

d of error correctly. Please check attached patch set. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ v23-0003-1-transformJsonExprCommon-fixup.patch Description: Binary data v23-0003-2-json-query-coercion-override.patch Description: Binary data

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

. Actually, I've asked here because there are several references to PG_PROC oids from other tables in the system catalog, so I was worried if this logic could break something I do not know about. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

by some extension and saved and re-processed automatically or by user's request, but without bothering user with these internal keys. The main question - maybe, are there pitfalls of which I am not aware of? Thanks for your replies! -- Regards, Nikita Malakhov Postgres Professional The Russian

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

of pg_upgrade (pg_dump and func/procedure creation function). I've read previous threads about using regproc, and agree that this is not a very good case anyway, but I haven't found any serious obstacles that forbid modifying pg_upgrade this way. -- Regards, Nikita Malakhov Postgres Professional

Pro et contra of preserving pg_proc oids during pg_upgrade

Hi hackers! Please advise on the idea of preserving pg_proc oids during pg_upgrade, in a way like relfilenodes, type id and so on. What are possible downsides of such a solution? Thanks! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

> > Speaking of the tests I suggest adding a bit more comments before > every (or most) of the queries. Figuring out what they test could be > not particularly straightforward for somebody who will make changes > after the patch will be accepted. > > [1]: http://cfbot.cputube.org/ > [2]: https://github.com/afiskon/pgscripts/ > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

acing_planner_hook psql:/home/postgres/tests/trace.sql:52: NOTICE: pg_tracing_ExecutorStart psql:/home/postgres/tests/trace.sql:52: NOTICE: pg_tracing_ExecutorRun psql:/home/postgres/tests/trace.sql:52: NOTICE: pg_tracing_ExecutorFinish psql:/home/postgres/tests/trace.sql:52: NOTICE: pg_traci

Re: POC: Extension for adding distributed tracing - pg_tracing

d to span and made a table and an sql function that flushes spans to this table instead of returning set or records - it is more convenient for the maintenance to query the table. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

check the patch for the race conditions. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

> > Agree, something goes wrong when using Autotools (but not Meson) on > both Linux and MacOS. I didn't investigate the issue though. > > -- > Best regards, > Aleksander Alekseev > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ pg-tracing-v2.patch Description: Binary data

Re: POC: Extension for adding distributed tracing - pg_tracing

Hi, Also FYI, there are build warnings because functions const char * get_span_name(const Span * span, const char *qbuffer) and const char * get_operation_name(const Span * span, const char *qbuffer) do not have default inside switch and no return outside of switch. -- Regards, Nikita Malakhov

Re: POC: Extension for adding distributed tracing - pg_tracing

local/pgsql/lib/pg_tracing.so": /usr/local/pgsql/lib/pg_tracing.so: undefined symbol: get_operation_name Thank you! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ mc.log Description: Binary data

Re: POC: Extension for adding distributed tracing - pg_tracing

6/ > > -- > Best regards, > Aleksander Alekseev > > > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Protect extension' internal tables - how?

. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Protect extension' internal tables - how?

of solution? Thanks in advance. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

Hi! Aleksander, thank you for reminding me of this patch, try to do it in a few days. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: pg_column_toast_chunk_id: a function to get a chunk ID of a TOASTed value

of valueid + chunk_seq. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Pluggable toaster

more promising in terms of performance and storage improvements. We already have a lot of changes in Pluggable TOAST that were not committed to the main GIT branch of this thread, so it seems that I have to merge them and reopen it. -- Regards, Nikita Malakhov Postgres Professional The Russian

Re: Pluggable toaster

ssage-id/flat/CAJ7c6TNAYyeMYKVkiwOZChy7UpE_CkjpYOk73gcWTXMkLkEyzw%40mail.gmail.com#59aacdde27dd61277fe7c46c61c84b2c> -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: RFI: Extending the TOAST Pointer

- extending TOAST pointer with additional structures would require review of the logical replication engine, currently it is not suitable for any custom TOAST pointers. Currently we have no final solution for problems with logical replication for custom TOAST pointers. -- Regards, Nikita Malakhov Postgres

Re: RFI: Extending the TOAST Pointer

rZyQ%40mail.gmail.com > [2]: https://commitfest.postgresql.org/43/4296/ > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: RFI: Extending the TOAST Pointer

indicator, but I don't > think it's currently assumed to be a length indicator anyway (see > VARSIZE_EXTERNAL(ptr)). By not using the varatt_external struct > currently in use, we could be able to get down to <18B toast pointers > as well, though I'd consider that unlikely. > > Kind regards, > > Matthias van de Meent > Neon, Inc. > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

one later. >> >> [1]: >> https://www.postgresql.org/message-id/CAJ7c6TPSvR2rKpoVX5TSXo_kMxXF%2B-SxLtrpPaMf907tX%3DnVCw%40mail.gmail.com >> >> -- >> Best regards, >> Aleksander Alekseev >> > > > -- > Regards, > > -- > Nikita Malakhov > Postgres Professional > The Russian Postgres Company > https://postgrespro.ru/ > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

RFI: Extending the TOAST Pointer

org/message-id/flat/CAJ7c6TOtAB0z1UrksvGTStNE-herK-43bj22%3D5xVBg7S4vr5rQ%40mail.gmail.com> [4] BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table. <https://www.postgresql.org/message-id/flat/16722-93043fb459a41073%40postgresql.org> -- Regards, Nikita

Re: [PATCH] Compression dictionaries for JSONB

3DnVCw%40mail.gmail.com > > -- > Best regards, > Aleksander Alekseev > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

the community in > the long term. > > Thoughts? > > [1]: https://commitfest.postgresql.org/43/3626/ > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Doc limitation update proposal: include out-of-line OID usage per TOAST-ed columns

: > On Fri, Apr 21, 2023 at 12:14 AM Nikita Malakhov > wrote: > > This limitation applies not only to wide tables - it also applies to > tables where TOASTed values > > are updated very often. You would soon be out of available TOAST value > ID because in case of &g

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

Hi! No, it wasn't. It was a proposal, I thought I'd get some feedback on it before sending it to commitfest. On Sat, Apr 22, 2023 at 6:17 PM Gurjeet Singh wrote: > On Thu, Dec 22, 2022 at 10:07 AM Nikita Malakhov > wrote: > > Any suggestions on the previous message (64-bit to

Re: Doc limitation update proposal: include out-of-line OID usage per TOAST-ed columns

459a41073%40postgresql.org > > > [1] https://www.postgresql.org/message-id/CAN-LCVPRvRzxeUdYdDCZ7UwZQs1NmZpqBUCd%3D%2BRdMPFTyt-bRQ%40mail.gmail.com -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

this to be possible, due to e.g. > partitioning resulting in columns that share compressable patters to > be on different physical tables. > > > * TOAST currently doesn't support ZSTD. IMO this is not a big deal and > > adding the corresponding support can be discussed separately. > > * If memory serves, there were not so many free bits left in TOAST > > pointers. The pointers don't store a storage strategy though so > > hopefully this will not be a problem. We'll see. > > The toast pointer must store enough info about the compression used to > decompress the datum, which implies it needs to store the compression > algorithm used, and a reference to the compression dictionary (if > any). I think the idea about introducing a new toast pointer type (in > the custom toast patch) wasn't bad per se, and that change would allow > us to carry more or different info in the header. > > Kind regards, > > Matthias van de Meent > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: SQL/JSON revisited

NULL; } > ; > > Surely this can be made cleaner. > > By the way -- that comment about clauses being non-standard, can you > spot exactly *which* clauses that comment applies to? > > -- > Álvaro Herrera PostgreSQL Developer — > https://www.EnterpriseDB.com/ > "El número de instalaciones de UNIX se ha elevado a 10, > y se espera que este número aumente" (UPM, 1972) > > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: SQL JSON path enhanced numeric literals

> > > since that's different from the main lexer's syntax. > > done > > > Perhaps it's worth mentioning that difference in the docs. > > done > > > Otherwise, this looks good to me. > > committed > > > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: JsonPath version bits

Hi hackers! Could the 1 byte from the JsonPath header be used to store version? Or how many bits from the header could be used for the version value? On Mon, Mar 27, 2023 at 12:54 PM Nikita Malakhov wrote: > Hi hackers! > > I've got a question on the JsonPath header - currently the he

JsonPath version bits

is it possible to use to store a version value? Thanks! -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

ately (similarly to how TOAST does this)? > > Good point - should have been clearer. I meant attribute wise compression. > Like we do today, except that we would use a dictionary to increase > compression rates. > > Andres > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

t; dictionary for this table that you refresh from time to time. Very > > > simple. > > > > You cannot "just" refresh a dictionary used once to compress an > > object, because you need it to decompress the object too. > > Right. That's what I was trying to refer to when mentioning that we might > need > to add a bit of additional information to the varlena header for datums > compressed with a dictionary. > > Greetings, > > Andres Freund > -- Regards, -- Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Pluggable toaster

ht that the most complex and questionable part would be the TOAST implementations (the Toasters) itself, and the Pluggable TOAST is just a tool to make plugging different TOAST implementations clean and simple. -- Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Pluggable toaster

to integrate the Pluggable TOAST into the vanilla, along with our advanced TOAST implementations which we plan to keep under Open Source licenses too. On Mon, Feb 6, 2023 at 1:49 PM Alvaro Herrera wrote: > On 2023-Feb-06, Nikita Malakhov wrote: > > > Currently we're busy revising the who

Re: Pluggable toaster

on at all. Currently we're busy revising the whole Pluggable TOAST API to make it available as an extension and based on hooks to minimize changes in the core. It will be available soon. > [1] https://postgr.es/m/20230203095540.zutul5vmsbmantbm@alvherre.pgsql > -- Nikita Malakhov Postgr

Re: Inconsistency in vacuum behavior

produce cache lookup ERRORs if the > relation is concurrently dropped. > > -- > Nathan Bossart > Amazon Web Services: https://aws.amazon.com > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: run pgindent on a regular basis / scripted manner

t; Álvaro Herrera 48°01'N 7°57'E — > https://www.EnterpriseDB.com/ > #error <https://www.EnterpriseDB.com/#error> "Operator lives in the wrong > universe" > ("Use of cookies in real-time system development", M. Gleixner, M. Mc > Guire) > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Inconsistency in vacuum behavior

Justin Pryzby писал 2023-01-19 04:49: > > On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote: > >> Hi, > >> > >> Currently there is no error in this case, so additional thrown error > >> would > >> require a new test. > >> Be

Re: Inconsistency in vacuum behavior

Hi! I've found the discussion you'd mentioned before, checking now. On Thu, Jan 19, 2023 at 4:49 AM Justin Pryzby wrote: > On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote: > > Hi, > > > > Currently there is no error in this case, so additional thrown erro

Re: Inconsistency in vacuum behavior

Hi hackers! Alexander found a very good issue. Please check the solution above. Any objections? It's a production case, please review, any thoughts and objections are welcome. On Mon, Jan 16, 2023 at 8:15 PM Alexander Pyhalov wrote: > Nikita Malakhov писал 2023-01-16 20:12: >

Re: Inconsistency in vacuum behavior

or objections? On Mon, Jan 16, 2023 at 7:46 PM Alexander Pyhalov wrote: > Nikita Malakhov писал 2023-01-16 17:26: > > Hi! > > > > Here's the patch that fixes this case, please check it out. > > The patch adds vacuum_is_permitted_for_relation() check before adding > >

Re: Inconsistency in vacuum behavior

the lock. Cheers! On Mon, Jan 16, 2023 at 4:48 PM Nikita Malakhov wrote: > Hi! > > I've checked this expand_vacuum_rel() and made a quick fix for this.Here's > the result of the test: > > postgres@postgres=# set role regress_vacuum_conflict; > SET > Time: 0.369 ms >

Re: Inconsistency in vacuum behavior

check will be performed later in vacuum_rel(), but after > vacuum_open_relation(), which leads to hang in the second session. > > Is it intended? Why don't we perform vacuum_is_permitted_for_relation() > check for inheritors in expand_vacuum_rel()? > > -- > Best regards, > Alexander Pyhalov, > Postgres Professional > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Pluggable toaster

Hi! Fails due to recent changes. Working on it. On Sat, Jan 14, 2023 at 9:56 AM vignesh C wrote: > On Sun, 8 Jan 2023 at 01:40, Nikita Malakhov wrote: > > > > Hi! > > > > Thank you for your attention. > > I've rebased the patchset onto the latest master (f

Re: How to define template types in PostgreSQL

pes such as anyarray, anyrange, anymultirange, ... > > Is there a possibility that we can also define pseudo types such as > anyset, anyspan, anyspanset, anytemporal, ? > > This will considerably reduce the number of SQL functions to define. > Currently, given the high number of f

Re: split TOAST support out of postgres.h

nno, #3 seems kind of unprincipled. Also, since fmgr.h is included > so widely, I doubt it is buying very much in terms of reducing header > footprint. How bad is it to do #2? > > regards, tom lane > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Passing relation metadata to Exec routine

that passing these parameters in a backdoor fashion is not very transparent and user-friendly, too. On Tue, Dec 27, 2022 at 12:56 AM Tom Lane wrote: > Nikita Malakhov writes: > > While working on Pluggable TOAST [1] we found out that creation > > of new relation with CREATE TABLE

Passing relation metadata to Exec routine

/ -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: ARRNELEMS Out-of-bounds possible errors

Hi, My bad, I was misleaded by unconditional return in ereturn_domain. Sorry for the noise. On Sat, Dec 24, 2022 at 7:05 PM Tom Lane wrote: > Nikita Malakhov writes: > > Even with null context it does not turn to ereport, and returns dummy > value > > Read the code. Arr

Re: ARRNELEMS Out-of-bounds possible errors

> No.. It seems to me that the commit didn't change its behavior in that > regard. > > > Of course teaching Coverity not to issue the false warnings would be > > another actual issue that we should do, maybe. > > -- > Kyotaro Horiguchi > NTT Open Source Software Center > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: ARRNELEMS Out-of-bounds possible errors

of code needs to be revised. On Fri, Dec 23, 2022 at 1:20 AM Ranier Vilela wrote: > Em qui., 22 de dez. de 2022 às 15:45, Nikita Malakhov > escreveu: > >> Hi, >> >> Actually, there would be much more sources affected, like >> nbytes += subbytes[out

Re: ARRNELEMS Out-of-bounds possible errors

ELEMS(ent); > memcpy(ptr, ARRPTR(ent), nel * sizeof(int32)); > } > > Sources possibly affecteds: > contrib\cube\cube.c > contrib\intarray\_intbig_gist.c > contrib\intarray\_int_bool.c > contrib\intarray\_int_gin.c > contrib\intarray\_int_gist.c > contrib\intarray\_i

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

Hi hackers! Any suggestions on the previous message (64-bit toast value ID with individual counters)? On Tue, Dec 13, 2022 at 1:41 PM Nikita Malakhov wrote: > Hi hackers! > > I've prepared a patch with a 64-bit TOAST Value ID. It is a kind of > prototype > and needs so

Re: Array initialisation notation in syscache.c

it works, but it does indeed seem to work and > > this should make cfbot green. > > This looks like a good improvement to me. > > (I have also thought about having this generated from the catalog > definition files somehow, but one step at a time ...) > > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: meson and tmp_install

Freund wrote: > Hi, > > On 2022-12-20 21:11:26 +0300, Nikita Malakhov wrote: > > Didn't know where to ask, so I've chosen this thread - there is no any > > documentation on meson build platform in PostgreSQL docs. > > There is now: > https://www.postgresql.org/docs/deve

Re: meson and tmp_install

the build > directory itself. The temp-install adds a fair bit of overhead and > failure potential. The only reason we need it is that a) initdb and a > few other programs insist that postgres needs to be in the same > directory b) contrib modules currently need to reside in

Re: New strategies for freezing, advancing relfrozenxid early

editorialize too much while just moving code around. +1 from me. > > > -- > Jeff Davis > PostgreSQL Contributor Team - AWS > > > > > -- Regards, -- Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Patch: Global Unique Index

index X. > > 3) when an insertion inserting a conflict value on index Y, > 3.1) it waits for buffer block lock if the lock has been held by > the insertion on index X. > 3.2) then, it waits for transaction lock until the insertion on > index X is done. > > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: On login trigger: take three

ity level we have. > This convinces me even more that the observed level of performance drop is > acceptable. > -- > best regards, > Mikhail A. Gribkov > > e-mail: youzh...@gmail.com > *http://www.flickr.com/photos/youzhick/albums > <http://www.flickr.com/photos/youzhick/albums>* > http://www.strava.com/athletes/5085772 > phone: +7(916)604-71-12 > Telegram: @youzhick > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: New strategies for freezing, advancing relfrozenxid early

kipping strategy". That's phrased as a kind of negative -- what we're > *not* doing. Many times I had to pause and compute in my head what we're > *doing*, i.e. the "scanning strategy". For example, I wonder if the VM > strategies would be easier to read as: > > VMSNA

  1   2   >