[PATCH] RUM Postgres 13 patch

Dear hackers! Due to changes in PG13 RUM extension had errors on compiling. I propose a short patch to correct this. Best regards, Pavel Borisov rum_pg13_patch.diff Description: Binary data

Re: [PATCH] fix GIN index search sometimes losing results

function for GIST and GIN now gives ternary result and is called with ternary type callback. I think in future nothing prevents smoothly shifting callback functions, check functions and even TS_execute result to ternary. So I also send my variant patch for review and discussion. Regards, Pavel Borisov

[PATCH] fix GIN index search sometimes losing results

'::tsquery refuse to find 'crew:BCD'::tsvector Seems it is in all versions of PG. The patch is intended to deal with the issue. Also it contains tests for these rare condition. Pavel Borisov. gin-weights-patch-v3.diff Description: Binary data

Fwd: [PATCH] fix GIN index search sometimes losing results

st regards, Pavel Borisov. вс, 17 мая 2020 г. в 23:53, Pavel Borisov : > Hi, all! > Below is my variant how to patch Gin-Gist weights issue: > 1. First of all I propose to shift from previously Gin's own TS_execute > variant and leave only two: TS_execute with bool result and bool type

Re: PoC: custom signal handler for extensions

eing used as a part of the pg_query_state extension during several major PostgreSQL releases. So I'd like to raise the matter of reviewing this updated patch and include it into version 14 as I see much use of this change. I welcome all your considerations, -- Best regards, Pavel Borisov Postgres Pro

Re: [PATCH] Covering SPGiST index

tts + 1. > I placed this check only once on SpGist state creation and replaced the other checks to asserts. > Also I'd refactor this > + /* Form descriptor for INCLUDE columns if any */ > Also done. Thanks a lot! See v10. -- Best regards, Pavel Borisov Postgres Professional: ht

Re: [PATCH] Covering SPGiST index

m not sure would it be helpful to use instead of > >isnull[0] and leafDatum[0] > more complex > >#define SpgKeyIndex 0 > >isnull[SpgKeyIndex] and leafDatum[SpgKeyIndex] > There is so many [0] in the patch... > I agree with all of your proposals and integrated them into

Re: Yet another fast GiST build (typo)

> > Pavel sent me few typos offlist. PFA v12 fixing these typos. > Thanks! > Now I consider the patch ready to be committed and mark it so on CF. Thank you! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Yet another fast GiST build

> > Interesting to see also the size of index, it should be several times less. > > I've tested this above in CF thread and got ordered GiST index ~1.7 times smaller than non-ordered one for single column of real points. -- Best regards, Pavel Borisov Postgres Profes

Re: [PATCH] Automatic HASH and LIST partition creation

and much simpler to use compared to declarative partitioning to date. Thanks! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Yet another fast GiST build

haven't tested performance as a function of coordinate. So I feel this patch is not about select speed optimization. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Yet another fast GiST build

> > > >> I suppose there is a big jump in integer value (whether signed or > >> unsigned) as you cross from positive to negative floats, and then the > >> sort order is reversed. I have no idea if either of those things is a > >> problem worth fixing. That made me wonder if there might also be

Re: [PATCH] Automatic HASH and LIST partition creation

> > Do you think that it is a bug? For now, I removed this statement from > tests just to calm down the CI. > It is in accordance with changes in tests for vanilla decralarive partitioning as per commit 2dfa3fea88bc951d0812a18649d801f07964c9b9 Author: Tom Lane Date: Mon Sep 28 13:44:01 2020

Re: [PATCH] Automatic HASH and LIST partition creation

ea is to add a prefix to partitions is to give the possibility to specify it for users. So the user will be able to choose appropriate and not very long suffix to avoid conflicts. Maybe like this: CREATE TABLE city (a text) PARTITION BY LIST (a) CONFIGURATION (VALUES IN ('a','b'),('c','d') DEFAULT PARTITION city_other PREFIX _prt) ; Result: --- city_prt1 city_prt2 ... city_other -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Automatic HASH and LIST partition creation

is immediate, so using word IMMEDIATE seems a little bit redundant to me. We may introduce this word together with adding DEFERRED option. However, my opinion is not in strong opposition to both options. Оther opinions are very much welcome! -- Best regards, Pavel Borisov Postgres Professional

Re: Yet another fast GiST build

commit 0a3c864c32751fd29d021929cf70af421fd27370 after all changes into Gist committed. cflags="-DUSE_VALGRIND -Og -O0 -fsanitize=address -fsanitize=undefined -fno-sanitize-recover=all -fno-sanitize=alignment -fstack-protector" -- Best regards, Pavel Borisov Postgres Professional: http://postg

Re: Yet another fast GiST build

It became normal with -fsanitize=signed-integer-overflow,null,alignment instead of -fsanitize=undefined (which is strictly a 'default' list of needed and unnecessary things to check, can be overridden anyway but needed some reading for it) Thanks! -- Best regards, Pavel Borisov Postgres

Re: [PATCH] Automatic HASH and LIST partition creation

much trouble in any form of automatic naming. But there may be a convenience to provide fixed user-specified prefix to partition names. Thank you, -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Yet another fast GiST build

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested I consider this patch almost ready for commit with minor corrections

Re: [PATCH] Covering SPGiST index

ypes declarations to insert pointer "SpGistLeafTuple leafTuple"; into struct SpGistSearchItem. This is the only change in this block and I apologize for possible inconvenience to review this change. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http:

Re: [PATCH] Covering SPGiST index

> > I'm looking into the patch. I have few notes: > > 1. I see that in src/backend/access/spgist/README you describe SP-GiST > tuple as sequence of {Value, ItemPtr to heap, Included attributes}. Is it > different from regular IndexTuple where tid is within TupleHeader? > Yes, the header of SpGist

Re: Yet another fast GiST build (typo)

deed, that were fixups: point converted to GiST representation is a bbox > already, and the function expects only bboxes. > > Also I've fixed some mismerges in documentation. > > Thanks! > > Best regards, Andrey Borodin. > > -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Covering SPGiST index

With a little bugfix вт, 11 авг. 2020 г. в 22:50, Pavel Borisov : > > > вт, 11 авг. 2020 г. в 12:11, Pavel Borisov : > >> I added changes in documentation into the patch. >> >> >> -- >> Best regards, >> Pavel Borisov >> >

Re: [PATCH] fix GIN index search sometimes losing results

ave TS_EXEC_CALC_NOT definition in ts_utils.h but in general I'd like to save default behaviour of TS_execute and not apply patch 0002. Maybe it is only worth to leave notice in a comments in code that TS_EXEC_CALC_NOT left for compatibilty reasons etc. I'd appreciate any ideas and review of all aforemention

Valgrind run error with Postgres on OSX

have ideas on the issue please share. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v1-0001-Fix-for-bug-when-running-Valgrind-on-OSX.patch Description: Binary data

Re: POC: GROUP BY optimization

3e76cc571e ) 3. Tests are changed to represent changes in keys numbering and naming convention in the plan ( 55a1954da16 and 6ef77cf46e8 ) As always your ideas are very much welcome! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v11

Re: POC: GROUP BY optimization

atches and then re-decide what we want more to have a more complicated or a simpler version. Good to know that this feature is not stuck anymore and we have more than one proposal. Thanks! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Yet another fast GiST build

6945-c147-5afc-7720-38ec6848dafa%40gmail.com#9be5b8a75c4921498748514cb77c6e68 The main point is that buffering build is better to be enforced with buffering=on as otherwise buffering build becomes hard to test in the presence of sort support. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

[PATCH] Covering SPGiST index

this changes only affect private index structures so all outside behavior like WAL, vacuum etc will remain unchanged. As usual I very much appreciate your feedback -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> spgist-coverin

Re: [PATCH] Covering SPGiST index

Also little bit corrected code formatting. > Best regards, > Pavel Borisov > > Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> > spgist-covering-0003.diff Description: Binary data

Re: [PATCH] Covering SPGiST index

вт, 11 авг. 2020 г. в 12:11, Pavel Borisov : > I added changes in documentation into the patch. > > > -- > Best regards, > Pavel Borisov > > Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> > v5-0001-Covering-SP-GiST-index-support-for

Re: [PATCH] Covering SPGiST index

Same code formatted as a patch. пн, 10 авг. 2020 г. в 17:45, Pavel Borisov : > Also little bit corrected code formatting. > >> Best regards, >> Pavel Borisov >> >> Postgres Professional: http://postgrespro.com >> <http://www.postgrespro.com> >&g

Re: [PATCH] Covering SPGiST index

I added changes in documentation into the patch. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v4-0001-Covering-SP-GiST-index-support-for-INCLUDE-column.patch Description: Binary data

Re: [PATCH] Covering SPGiST index

g for the case when user wants to invoke index build with not one column. Thanks! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> spgist-covering-0002.diff Description: Binary data

Re: [PATCH] fix GIN index search sometimes losing results

ср, 1 июл. 2020 г. в 23:16, Tom Lane : > Pavel Borisov writes: > > Below is my variant how to patch Gin-Gist weights issue: > > I looked at this patch, but I'm unimpressed, because it's buggy. > Thank you, i'd noticed and made minor corrections in the patch. Now it sho

Re: [PATCH] fix GIN index search sometimes losing results

чт, 2 июл. 2020 г. в 19:38, Artur Zakirov : > Hello, > > On Thu, Jul 2, 2020 at 8:23 PM Pavel Borisov > wrote: > > > > ср, 1 июл. 2020 г. в 23:16, Tom Lane : > >> > >> Pavel Borisov writes: > >> > Below is my variant how to patch Gin-Gist we

Re: [PATCH] fix GIN index search sometimes losing results

make code more beautiful but possibly will not give some performance gain and bug is anyway fixed by patch 0001. Overall I'd recommend patch 0001-make-callbacks-ternary.patch and close the issue. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com The new status of

Re: Building 12.3 from source on Mac

I'd like to add that MacPorts installs everything to /opt/ and /opt/local unless someone configures other path. You can also easily check is something from homebrew installation by running 'brew config' and looking at HOMEBREW_PREFIX entry. Regards, Pavel чт, 23 июл. 2020 г. в 19:05, Paul

Re: [PATCH] fix GIN index search sometimes losing results

ср, 22 июл. 2020 г. в 19:10, Tom Lane : > Pavel Borisov writes: > > For 0002-remove-calc-not-flag.patch > > The patch changes the behavior which is now considered default. This is > true in RUM module and maybe in some other tsearch side modules. Applying > the patch can mak

Re: Is postgres ready for 2038?

> There are no 32bit Windows version builds since Postgres 11, see: > > https://www.postgresql.org/download/windows/ > > but Postgres 13 still has the same 2038 problems. > > > > As @Pavel Borisov hints , I can find `_USE_32BIT_TIME_T` code here: > > https://gith

Re: [PATCH] Covering SPGiST index

ate.h to their initial places where possible and made other cosmetic changes to improve the patch. PFA v.11 of the patch. Do you think the proposed changes are in the right direction? Thank you! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.

Re: Corner-case bug in pg_rewind

> > Ok, pushed and backpatched this now. > Very nice! Thanks to you all! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Covering SPGiST index

I've noticed CI error due to the fact that MSVC doesn't allow arrays of flexible size arrays and made a fix for the issue. Also did some minor refinement in tuple creation. PFA v12 of a patch. чт, 26 нояб. 2020 г. в 21:48, Pavel Borisov : > > The way that seems acceptable to me is

Re: [PATCH] Covering SPGiST index

> > The cfbot's still unhappy --- looks like you omitted a file from the > patch? > You are right, thank you. Corrected this. PFA v13 -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v13-0001-Covering-SP-GiST-index-s

Re: Corner-case bug in pg_rewind

чт, 3 дек. 2020 г. в 19:15, Heikki Linnakangas : > On 03/12/2020 16:49, Pavel Borisov wrote: > > Ok, pushed and backpatched this now. > > > > Very nice! > > Thanks to you all! > > Thanks for the review, Pavel! I just realized that I forgot to credit >

Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted

finalize my own review and mark the patch as ready for committer if nobody has objections. Thank you! Pavel Borisov The new status of this patch is: Ready for Committer

Re: Speeding up GIST index creation for tsvectors

optimize index structure, minimizing disc pages access, etc. seems better in many cases. Thank you for your proposal! [1] https://commitfest.postgresql.org/29/2276/ [2] https://commitfest.postgresql.org/31/2824/ [3] https://github.com/postgrespro/rum -- Best regards, Pavel Borisov Postgres

Re: Corner-case bug in pg_rewind

ts I left were purely cosmetic. It's a pity to me that this bugfix delayed for such a small reason and outdated, therefore. It would be nice to complete this fix on the next CF. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Automatic HASH and LIST partition creation

possible to change the syntax of declarative partitioning too? It is problematic as it is already committed but also is very tempting to have the same type of syntax both in automatic partitioning and in manual (PARTITION OF...) -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Automatic HASH and LIST partition creation

se than my proposal above. Still other opinions are highly valued. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Automatic HASH and LIST partition creation

add RANGE partitioning syntax to this in the future and I will be happy if all three types of the syntax could come along easily. I very much appreciate your views on this especially regarding that changes can be still made easily because the patch is not committed yet. -- Best regards, Pavel Borisov

Re: [PATCH] Automatic HASH and LIST partition creation

e.DEB.2.21.1907150711080.22273%40lancre -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Automatic HASH and LIST partition creation

BTW could you tell me a couple of words about pros and cons of c-code syntax parsing comparing to parsing using gram.y trees? I think both are possible but my predisposition was that we'd better use the later if possible. Best regards, Pavel Borisov >

Re: Corner-case bug in pg_rewind

a minor improvement described. Thank you! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Combine same ternary types in GIN and TSearch

e them and use them like we use other global data types. We may declare it somewhere outside both gin and search. Or just leave as it is. Thank you, Heikki for your feedback! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Bogus documentation for bogus geometric operators

t;^ for point type (but this is not the only way so I haven't done this in v5). What do you think? -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v5-0001-Deprecate-and-replace-and-operators-for-points.patch Description: Binary data

[PATCH] Combine same ternary types in GIN and TSearch

inclusion in some modules. What do you think about this? -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v1-0001-Combine-same-types-GinTernaryValue-and-TSTernaryV.patch Description: Binary data

Re: Corner-case bug in pg_rewind

t also. But I don't insist. > Note that the patch may require reworking for HEAD due to changes in > commit 9c4f5192f6. I'll try to take another look this week. > Thank you! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Evaluate expression at planning time for two more cases

in the thread should be a must-do for this patch. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com The new status of this patch is: Waiting on Author

Re: Heads-up: macOS Big Sur upgrade breaks EDB PostgreSQL installations

and will not generally modify its contents during migration betweeb osx versions and/or different machines. It is not only the question of permissions. Any options inside user homedir are equally suitable IMO. --- Best regards, Pavel Borisov Postgres professional: http://postgrespro.com

Re: Is postgres ready for 2038?

Yes, I agree. ср, 18 нояб. 2020 г. в 18:44, Tom Lane : > Pavel Borisov writes: > >> Maybe we need to dig a little more to see what's going on here. > > > How about just a mention in the future documentation to never ever define > > _USE_32BIT_TIME_T when compili

Re: Is postgres ready for 2038?

. > How about just a mention in the future documentation to never ever define _USE_32BIT_TIME_T when compiling PG under Windows? Should be enough, I suppose. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Is postgres ready for 2038?

. I suppose that some 10+ years later the number of users willing to compile on 32-bit with dinosaur-aged Perl distribution will be nearly zero. So I suppose just mention this would be a funny fact in the documentation. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: bad logging around broken restore_command

patch and found it perfectly working with installcheck-world passed, code is clean. As for the feature I agree with Jeff and Fuji that this ENOENT case is worth logging under LOG priority. I consider the last (Fuji's) patch is now ready to be committed. Best regards, Pavel Borisov The new status

Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted

pace */ 349 do_truncate(path); . 356 * Delete any additional segments. 357 */ 358 if (ret >= 0) --^^^ -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Covering SPGiST index

вт, 17 нояб. 2020 г. в 11:36, Pavel Borisov : > I've started to review this, and I've got to say that I really disagree >> with this choice: >> >> + * If there are INCLUDE columns, they are stored after a key value, each >> + * starting from its own typalign boundar

Re: Bogus documentation for bogus geometric operators

apply and make the final checks soon. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Bogus documentation for bogus geometric operators

names yet. So for now, we have to support both names in the opclasses. > I extended the patch to do that. > > This version seems committable to me --- any thoughts? > The wording seems no problem to me. I looked into a patch and changes also seem sensible but I can not apply this patch becaus

Re: Bogus documentation for bogus geometric operators

it is ready to be pushed. Pavel Borisov

Re: Bogus documentation for bogus geometric operators

t have the same name and I'm planning to review the patch soon. What are your ideas on the possibility to backpatch it also? It seems a little bit weird that the operator can change its name between versions of PG. -- Best regards, Pavel Borisov Postgres Professional: http://postgr

Re: Bogus documentation for bogus geometric operators

Emre, could you please again rebase your patch on top of 2f70fdb0644c32c4154236c2b5c241bec92eac5e ? It is not applied anymore. > -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: [PATCH] Automatic HASH and LIST partition creation

. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: POC: GROUP BY optimization

t some useful changes which I've mentioned before, are discarded now. But as long as they are planned to be put in later it is completely fine. I agree to discuss the thing in any thread, though I don't quite understand the reason for a switch. Still I don't see a problem. -- Best regards, Pa

Re: Bogus documentation for bogus geometric operators

(1,2))'::box; -- f select '((0,0),(1,1))'::box <^ '((0,1),(1,2))'::box; -- t So I've only reverted the changes in the documentation on geometric functions in your patch. PFA v3 of your patch. I'd mark it ready to commit if you agree. Thank you! -- Best regards, Pavel Borisov Postgr

Re: Bogus documentation for bogus geometric operators

for box operators, > but remove the lines for the point operators. > Indeed you are right. PFA v4 with documentation removed for <^ and >^ for point Thanks! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v4-0001-Deprecate-and-replace-and-operators-for-points.patch Description: Binary data

Re: [PATCH] Automatic HASH and LIST partition creation

were seconded by anyone, I return the previous Ready-for-committer CF status. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> 0001-Auto-generated-HASH-and-LIST-partitions-v4.patch Description: Binary data

Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

By the way in the initial discussion on parallel infrastructure https://www.postgresql.org/message-id/20150208002027.GH9201%40alap3.anarazel.de I've seen a proposal to set the worker's PGXACT->xmin to be the minimum of the top transaction id and the snapshots. -- Best regards, Pavel Bori

Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

rallel infrastructure patch as per your commit 924bcf4f16d ? Until then just a workaround like v3 patch seems safer for me (still I am not a very big specialist in this). -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: OOM in spgist insert

n't fit into one index page. As INCLUDED columns are added as is the tuple can not be made shorter by prefix-stripping. Seems we should check every index tuple length to fit the page before its insertion. Will see the code little bit later. Thanks for the reporting! -- Best regards, Pavel Borisov

Re: OOM in spgist insert

ср, 12 мая 2021 г. в 12:36, Dilip Kumar : > On Wed, 12 May 2021 at 1:43 PM, Pavel Borisov > wrote: > >> ср, 12 мая 2021 г. в 11:09, Dilip Kumar : >> >>> While testing something on spgist I found that at certain point while >>> inserting in spgist it is goin

Re: OOM in spgist insert

> > V2 works. Thanks for fixing this quickly, I think you can add a > comment for the new error condition you added. > Added comments. PFA v3 -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v3-0001-When-there-ar

Re: OOM in spgist insert

> > INCLUDEd -> why you have used a mixed case here? > It is current practice to call INCLUDE columns in capital, you can find many places in the current code. But case mixture can be avoided indeed )) PFA v4 v4-0001-When-there-are-INCLUDEd-columns-in-SpGist-check-t.patch Description: Binary

Re: OOM in spgist insert

I think it's good to backpatch the check as it doesn't change acceptable behavior, just replace infinite loop with the acceptable thing.

Re: OOM in spgist insert

ning, trySuffixing or > can(Try)ShortenTuple? > Or maybe it's even more logical now to invert it and make dontTrySuffixing for use in the opclasses for kd-tree, quadtree etc which are warranted to have the same key data length at any tree level ? -- Best regards, Pavel Borisov Postgres Professional

Re: OOM in spgist insert

)ShortenTuple? -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

it is a real and long-time-persistent error that is surely worth to be fixed. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: OOM in spgist insert

ср, 12 мая 2021 г. в 12:39, Pavel Borisov : > ср, 12 мая 2021 г. в 12:36, Dilip Kumar : > >> On Wed, 12 May 2021 at 1:43 PM, Pavel Borisov >> wrote: >> >>> ср, 12 мая 2021 г. в 11:09, Dilip Kumar : >>> >>>> While testing something on spg

Re: Let's get rid of serial_schedule

sing, so the v2 patch does it his way. > > Agreed, I like his phrasing too. +1 too. I'd also like to get rid of the redundant test schedule. Very much appreciate the initiative. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

solves the problem but it doesn't seem the right way to fix the issue. Instead it's better to process suboverflowed state which is legit itself not resulting getting the crash on the Assert. So the discussion of "better" value doesn't seem related to the problem. It is for demonstration on

Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

пн, 24 мая 2021 г. в 09:22, Greg Nancarrow : > On Mon, May 24, 2021 at 2:50 PM Michael Paquier > wrote: > > > > On Mon, May 24, 2021 at 12:04:37PM +1000, Greg Nancarrow wrote: > > > Keep cfbot happy, use the PG14 patch as latest. > > > > This stuff is usually very tricky. > > Agreed. That's why

Re: [PATCH] Automatic HASH and LIST partition creation

urely cosmetic. So I'd suppose the ready-for-committer status should not better have been changed. So I'd like return it to ready-for-committer. If you mind against this, please mention. The opinion of Nitin, a second reviewer, is also very much appreciated. -- Best regards, Pavel Borisov Postg

Re: [PATCH] Automatic HASH and LIST partition creation

ineRelation() > > +*/ > > + part_relname = psprintf("%s_%d", cxt->relation->relname, i); > > The assignment can be done directly while declaring the variable. > Thank you for your review! I've rebased the patch and made the changes mentioned. PFA

[PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

is case, there would be a message that recommends doing VACUUM to remove the invisible entries from the index and repeat the check. (Generally, it is recommended to do vacuum before the check, but for the testing purpose I'd recommend turning it off to check the detection of visible-invisible-visible

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

On Mon, 8 Feb 2021, 14:46 Pavel Borisov Hi, hackers! > > It seems that if btree index with a unique constraint is corrupted by > duplicates, amcheck now can not catch this. Reindex becomes impossible as > it throws an error but otherwise the index will let the user know that it &g

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

вт, 9 февр. 2021 г. в 01:46, Mark Dilger : > > > > On Feb 8, 2021, at 2:46 AM, Pavel Borisov > wrote: > > > > 0002 - is a temporary hack for testing. It will allow inserting > duplicates in a table even if an index with the exact name "idx" has a > un

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

To make tests stable I also removed lsn output under warning level. PFA v3 of a patch -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v3-0001-Make-amcheck-checking-UNIQUE-constraint-for-btree.patch Description: Binary data

Re: [PATCH] Covering SPGiST index

In a v14 I forgot to add the test. PFA v15 -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v15-0001-Covering-SP-GiST-index-support-for-INCLUDE-colum.patch Description: Binary data

Re: [PATCH] Covering SPGiST index

is not removed, it calls fetch_att. And I find this suitable as the address for the first tuple attribute is MAXALIGNed). Thanks again for your consideration. From now I hope to be able to work on the feature with not so big delay. -- Best regards, Pavel Borisov Postgres Professional: http://postgresp

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

iant regression test for 32 and 64 bit systems. Thank you for your consideration! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com> v4-0001-Make-amcheck-checking-UNIQUE-constraint-for-btree.patch Description: Binary data

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

of a patch to check? I've made tests portable in v3, probably, you've checked not the last version. Thanks for your attention to the patch -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

  1   2   3   4   >