Re: nbtsort.c performs unneeded (though harmless) truncation

truncations, while preserving the generic BTreeTupleGetNAtts() assertions. This isn't a correctness issue, and the extra overhead of unneeded truncation should be negligible, but what we have now seems confusing to me. -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

to ginFindLeafPage() with searchMode = false. Rebased patch is attached. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ commit 42f73743d9ddf576d2dd9ece3979b407cd70cbfe Author: Teodor Sigaev <

Re: doc fixes: vacuum_cleanup_index_scale_factor

thanks to everyone, pushed -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Postgres 11 release notes

/JSONB values (Dmitry Dolgov) to Add function json(b)_to_tsvector to create usable vectors to search in json(b) (Dmitry Dolgov) or somehow else. Your wording is about query but actually that functions are about how to create tsvector from json(b) Thank you! -- Teodor Sigaev

Re: Postgres 11 release notes

text search over json(b) columns. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Cast jsonb to numeric, int, float, bool

uot;); where the subroutine contains the whole ereport() call, and its lookup table entries are e.g. gettext_noop("cannot cast jsonb string to type %s") Thanks for your idea, patch is attached -- Teodor Sigaev E

Re: Cast jsonb to numeric, int, float, bool

How about "cannot cast jsonb $json_type to $sql_type" where $json_type is the type inside the jsonb (e.g. string, number, boolean, array, object)? Yes, that sounds pretty good. Does anybody have an objections to patch? -- Teodor Sigaev E

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

Thanks to everyone, v3 is pushed. Teodor Sigaev wrote: I don't very happy with rootBuffer added everywhere. ginInsertItemPointers() and   ginPrepareDataScan() now take both args, rootBlkno and rootBuffer, second could be invalid. As I can see, you did it to call CheckForSerializableConflictIn

Re: index scan over composite type

Thank you. Seems, it works, at least I can't find a counter-example for that. Tom Lane wrote: Teodor Sigaev <teo...@sigaev.ru> writes: I'm not understand why postgres prefers to sort table instead of using index only scan when query is a simple inner join on composite type. Query with eq

index scan over composite type

(cost=0.00..1834.00 rows=10 width=37) -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ test.sql Description: application/sql

Re: POC: GROUP BY optimization

ch follows that if I didn't a mistake. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: POC: GROUP BY optimization

cute query. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: POC: GROUP BY optimization

le/disable these options during development, because that makes experiments much easier. But then remove them before commit. Will do -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: POC: GROUP BY optimization

) provided by incremental sort patch and, it's a pity, it doesn't solve our problem with the impact of the cost of per-column comparison function and number of its calls. -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: POC: GROUP BY optimization

BY. In which case we don't add any Sort, of course. I hope so I'm still opposed to adding arbitrary handicap to prioritize the order specified by user, for the reasons I explained before. We should aim to make the heuristics/costing reliable enough to make this unnecessary. +1 -- Teodor

Re: POC: GROUP BY optimization

node. Incremental sort patch will improve cases where there is partial match of order. BTW I get compiler warnings that n_preordered_groups may be used uninitialized in add_paths_to_grouping_rel, because it's only set in an if/else branch, and then used further down. Fixed, but I believe tha

Re: Speedup of relation deletes during recovery

into situations where the standy starts to lag behind very significantly. +1, we faced with that too -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Few comments on commit 857f9c36 (skip full index scans )

The metapage upgrade should be performed under critical section. Agree. But after close look I found that btm_version change isn't wal-logged (near line 2251 in _bt_newroot). So btm_version is not propagated to replica/backup/etc. I believe it should be fixed. -- Teodor Sigaev

Re: Few comments on commit 857f9c36 (skip full index scans )

I think it will always be set to BTREE_VERSION (See _bt_restore_meta). You are right, pushed. Thank you! -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: POC: GROUP BY optimization

Cosmetics change: remove find_sort_group_clause_by_sortref() function added in v5 patch version because it duplicates existsing get_sortgroupref_clause(). -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http

POC: GROUP BY optimization

yet. 4) Algorithms to reorder columns is proportional to N^2 where N is number of columns, but I hope it isn't a problem because number of GROUP BY columns isn't very big usually. -- Teodor Sigaev E-mail: teo...@sigaev

Re: New committers announced at PGCon 2018

Etsuro Fujita Peter Geoghegan Amit Kapila Alexander Korotkov Thomas Munro Michael Paquier Tomas Vondra Congratulations to all! +7! -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: \d t: ERROR: XX000: cache lookup failed for relation

led for relation 1033478 ALTER TABLE ERROR: cache lookup failed for relation 1034073 ALTER TABLE ERROR: cache lookup failed for relation 1034650 ALTER TABLE ERROR: cache lookup failed for relation 1035238 ALTER TABLE ERROR: cache lookup failed for relation 1035837 will investigate -- Teodor Sig

Re: [PATCH] Trim trailing whitespace in vim and emacs

; || expand('%:e') == "pm" || expand('%:e') == "y" || expand('%:e') == "l" else let g:filestyle_plugin = 1 endif [1] https://www.vim.org/scripts/script.php?script_id=5065 -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: [PATCH] Trim trailing whitespace in vim and emacs

I use FileStly plugin to vim [1]. But I slightly modify it,  see in attachment. FileStyle, sorry. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: POC: GROUP BY optimization

this reordering optimization. The first part (additional indexes) seems quite fairly safe, likely to get committable soon. The other part (ndistinct reordering) IMHO requires more thought regarding costing and interaction with other query parts. Thank you for review! -- Teodor Sigaev

Re: \d t: ERROR: XX000: cache lookup failed for relation

Teodor Sigaev wrote: Ah, I think this is the missing, essential component: CREATE INDEX ON t(right(i::text,1)) WHERE i::text LIKE '%1'; Finally, I reproduce it with attached script. In attachment simplified version of script. psql uses ordinary sql query to get info about index with usual

Re: POC: GROUP BY optimization

olumn with 100k distinct values, with actual uniform distribution. I'm pretty sure it'd be more efficient to place the 100k column first. Interesting. Will think, thank you -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: \d t: ERROR: XX000: cache lookup failed for relation

Is that considered an actionable problem? I think so. but I'm not able to reproduce that, I wrote a script to simplify but it doesn't reproduce too. And how long to wait to reproduce? I waited for one hour -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: Corrupted btree index on HEAD because of covering indexes

Teodor, are you caught up to the point where it'd be okay to run pgindent, or are there still patches waiting? There is a gin predicate lock patch from Heikki, I will work on it. But I have not objection to run pgindent, I believe gin patch will be easy to change. -- Teodor Sigaev

Re: FinishPreparedTransaction missing HOLD_INTERRUPTS section

Postgres Company -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

and CheckForSerializableConflictIn() should be added to ginFindLeafPage() with searchMode = false. Implemented, v3 is attached. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ commit

Re: genomic locus

at runtime   size = LOCUS_SIZE(contig);   SET_VARSIZE(new_locus, size);   strcpy(new_locus->contig, contig); Is there a more direct way to clone a varlena structure (possibly assigning an differently-sized contig to it)? One that is also memory-safe? Store length of contig in LOCUS stru

Re: compress method for spgist - 2

Now, this patch is ready for committer from my point of view. Thank you, pushed -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: genomic locus

e of a monolithic type. I understand I could probably achieve the same cleanliness by defining functions and operators over the complex type, but by the time I’m done with that, will I have coded about the same amount of stuff as required to build an extended type? Regards, —Gene -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: CUBE seems a bit confused about ORDER BY

all cases such as C-functions, library functions for perl/python/etc languages. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: [HACKERS] PoC: custom signal handler for extensions

see an example of usage this API somewhere in contrib in exsting modules. Ideas? -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: pgbench - add \if support

for the noise. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: CUBE seems a bit confused about ORDER BY

move index support for this operator at all. And introduce new operator in HEAD with index support. This will need an upgrade script in minor versions -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: [HACKERS] pgbench more operators & functions

ct case when 1>0 then 33 when 1/0 > 0 then -33 else null end; case -- 33 -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: [HACKERS] pgbench more operators & functions

ed now, I believe, at least I see several test scenarios which can not be implemented with current pgbench and this patch allows to do it. So, I intend to push thish patch in current state. I saw several objections from commiters in thread, but, seems, that objections

Re: genomic locus

be equivalent to indexing the attributes of a composite type separately (if I understood it correctly). Ordering and GiST aren't very close things :) You can try to have a look to KNN-search feature of GiST. https://www.pgcon.org/2010/schedule/events/227.en.html -- Teodor Sigaev

Re: cost_sort() improvements

ms", Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, ISBN 0-07-013143-0 -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ diff --git a/src/backend/optimizer/path/costsize.c b/

Re: [PATCH] btree_gist: fix union implementation for variable length columns

It would be easier to figure this out if the btree_gist code weren't so desperately undocumented. Teodor, do you remember why it's like this? Will look. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http

Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index

com <http://www.postgrespro.com/> The Russian Postgres Company -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: json(b)_to_tsvector with numeric values

, improve. elog() should be used only for impossible error, whereas user input could contins mistakes. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: json(b)_to_tsvector with numeric values

Thank you, pushed with some editorization Dmitry Dolgov wrote: On 7 April 2018 at 17:09, Teodor Sigaev <teo...@sigaev.ru> wrote: See workable sketch for parsing jsonb flags and new worker variant. Yep, thanks for the sketch. Here is the new version of patch, does it look close to wh

Re: WIP: Covering + unique indexes.

Thanks to everyone, pushed. Peter Geoghegan wrote: On Sat, Apr 7, 2018 at 5:48 AM, Teodor Sigaev <teo...@sigaev.ru> wrote: On close look, bts_btentry.ip_posid is not used anymore, I change bts_btentry type to BlockNumber. As result, BTEntrySame() is removed. That seems like a goo

Re: WIP: Covering + unique indexes.

I'll keep an eye on the buildfarm, since it's late in Russia. Thank you very much! Now 23:10 MSK and I'll be able to follow during approximately hour. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Verbosity of genbki.pl

Opinions? Second point, pls. I'd like to see some stage done -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes.

'indnatts' [-Wunused-variable]   int   indnatts = tupleDescriptor->natts; Thank you, fixed -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes.

Thank you, fixed Jeff Janes wrote: On Sat, Apr 7, 2018 at 4:02 PM, Teodor Sigaev <teo...@sigaev.ru <mailto:teo...@sigaev.ru>> wrote: Thanks to everyone, pushed. Indeed thanks, this will be a nice feature. It is giving me a compiler warning on non-cassert builds using gcc (

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

not change metapage. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

the attached patch look sane to you? I like an idea use metapage locking, thank you. Patch seems good, will you push it? -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Optimization of range queries

;ID" >= 2068113880) AND ("ID" <= 2068629726)) (2 rows) Before starting  investigation of the problem, I will like to know opinion and may be some advise of people familiar with optimizer: how difficult will be to handle this case and where to look. Thanks in advance, -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes.

<noriyoshi.shin...@hpe.com> *Cc:* PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Teodor Sigaev <teo...@sigaev.ru>; Peter Geoghegan <p...@bowt.ie>; Jeff Janes <jeff.ja...@gmail.com>; Anastasia Lubennikova <a.lubennik...@postgrespro.ru> *Subject:* Re:

Re: Partitioned tables and covering indexes

ing indexes on partitioned tables.  See the attached patch. Seems right way, do not modify incoming object and do not copy rather large and deep nested structure as suggested by Amit. But it will be better to have a ATTACH PARTITION test too. -- Teodor Sigaev E-m

Re: WIP: Covering + unique indexes.

for you opinion? I do not have the time to write a patch right away, but I should be able to post one in a few days. I want to avoid sending several small patches. no problem, we can wait -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: [PATCH] btree_gin, add support for uuid, bool, name, bpchar and anyrange types

ng? Best regards, -- Matheus de Oliveira -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: json(b)_to_tsvector with numeric values

]) ? Agreed. Second arg should be optional. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Flexible configuration for full-text search

ERGE SQL Command) in master the patch doesn't apply due to a conflict in keywords lists (grammar and header). The new version of the patch without conflicts is attached. -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: Postgres stucks in deadlock detection

tion + let CheckDeadLock detect all deadlocks, not only those in which current transaction is involved. I think, it's better solution, but I'm afraid it's too late for 11v... -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: [PATCH] btree_gin, add support for uuid, bool, name, bpchar and anyrange types

, Apr 5, 2018 at 8:16 AM, Teodor Sigaev <teo...@sigaev.ru <mailto:teo...@sigaev.ru>> wrote: somehow you missed some parts in 0001 patch, at least regression tests fail:   CREATE EXTENSION btree_gin; + ERROR:  could not find function "gin_extract_value_uuid" in file

Re: new function for tsquery creartion

Thanks to everyone, pushed with some editorization: 1) translate russian test to prevent potential problems with encoding 2) fix inconsistency 'or cat' and 'cat or', second example doesn't treat OR as lexeme, but first one does. -- Teodor Sigaev E-mail

Re: [HACKERS] GUC for cleanup indexes threshold.

Postgres Professional:http://www.postgrespro.com <http://www.postgrespro.com/> The Russian Postgres Company -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Postgres stucks in deadlock detection

there are some read-only transactions, ~10 per second. We didn't invent this from mind, client came to us with support request, now we have two different cases. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Postgres stucks in deadlock detection

Have you ever observed that in the field? This sounds more artificial than real to me. Zabbix storage with 50Gb WAL per hour on insertion. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes.

. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Partitioned tables and covering indexes

Thank you, pushed Amit Langote wrote: Hi. On 2018/04/11 0:36, Teodor Sigaev wrote:     Does the attached fix look correct?  Haven't checked the fix with ATTACH     PARTITION though. Attached patch seems to fix the problem.  However, I would rather get rid of modifying stmt->indexPar

Re: Partitioned tables and covering indexes

more work: for (i = 0; i < info1->ii_NumIndexAttrs; i++) { if (maplen < info2->ii_KeyAttrNumbers[i]) Seems, we can go out from ii_KeyAttrNumbers array. Amit Langote wrote: Hi. On 2018/04/11 0:36, Teodor Sigaev wrote:     Does the attached fix look correct?  Hav

Re: Partitioned tables and covering indexes

Peter Geoghegan idea add a error message if somebody adds options to include column instead silently ignore it. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ diff --git a/src/backend/catalog/index.c b/src/backend/c

Re: Partitioned tables and covering indexes

columns. Otherwise the collation returned by an index-only scan would be different from a table scan, no? +1, dangerous -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Covering GiST indexes

-P0gDCtXbVDkBBG_WcXwCBK=gho4fewu...@mail.gmail.com -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Partitioned tables and covering indexes

, not a ii_NumIndexKeyAttrs number as easy to think. I suggest rename ii_KeyAttrNumbers to ii_AttrNumbers or ii_IndexAttrNumbers. Opinions?     for (i = 0; i < info1->ii_NumIndexAttrs; i++)     {     if (maplen < info2->ii_KeyAttrNumbers[i]) -- Teodor Sigaev

Re: Partitioned tables and covering indexes

pushed. Hope, second try will be successful. Teodor Sigaev wrote: Thank you, pushed Amit Langote wrote: Hi. On 2018/04/11 0:36, Teodor Sigaev wrote: Does the attached fix look correct?  Haven't checked the fix with ATTACH PARTITION though. Attached patch seems to fix the problem

Re: Partitioned tables and covering indexes

to use including column as key column 4) per Peter Geoghegan idea add a error message if somebody adds options to include column instead silently ignore it. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http

Re: psql leaks memory on query cancellation

nvironment set to 8192. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes.

der USE_ASSERT_CHECKING to prevent performance degradation. Users shouldn't pay for unused feature. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes.

Thank you, pushed. Peter Geoghegan wrote: On Sun, Apr 8, 2018 at 11:18 AM, Teodor Sigaev <teo...@sigaev.ru> wrote: Thank you, fixed I suggest that we remove some unneeded amcheck tests, as in the attached patch. They don't seem to add anything. -- Teodor Sigaev

Re: [HACKERS] [PATCH] Incremental sort

improvement for postponed ones doesn't seem to me very good, especially if it suggests some improvement right now. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes. (the good and the bad)

c2 from nt0___1 where c1 < 1 and c3 < 20 Not so fair comparison, include index twice bigger because of include columns. Try to compare with covering-emulated index: create unique index ${t}unique_idx on $t using btree (c1, c2, c3, c4) -- Teodor Sigaev E-

Re: [HACKERS] [PATCH] Incremental sort

by this patch.  Revised version is attached. Fine, patch got several rounds of review in all its parts. Is any places which should be improved before commit? -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

place for that in ginoptions function, but ginoptions doesn't has an access to relation structure and I don't see a reason why it should. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

Ugh, I miss your last email where you another locking protocol. Reading. Teodor Sigaev wrote: Attached is a test case that demonstrates a case where we miss a serialization failure, when fastupdate is turned on concurrently. It works on v10, but fails to throw a serialization error on v11

Re: WIP: Covering + unique indexes.

Thank you, I looked to buildfarm and completely forget about commitfest site Andres Freund wrote: On 2018-04-07 23:02:08 +0300, Teodor Sigaev wrote: Thanks to everyone, pushed. Marked CF entry as committed. Greetings, Andres Freund -- Teodor Sigaev E-mail: teo

Re: WIP: Covering + unique indexes.

missed. I can look at fixing these for you if you like? If you will do that I will be very grateful -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: json(b)_to_tsvector with numeric values

vector -- ! '123':7 '456':11 'aaa':1 'bbb':3 'ccc':5 'ddd':4 'fals':9,13 (1 row) -- ts_vector corner cases Dmitry Dolgov wrote: On 4 April 2018 at 16:09, Teodor Sigaev <teo...@sigaev.ru> wrote: Hm, seems, it's usefu

Re: json(b)_to_tsvector with numeric values

Dmitry Dolgov wrote: On 6 April 2018 at 16:25, Teodor Sigaev <teo...@sigaev.ru> wrote: 1) I don't like jsonb_all_to_tsvector too.. What if we will accept new variant to index? Let me suggest: tsvector jsonb_to_tsvector([regclass,] jsonb, text[]) where text[] arg is actually a flags,

Re: WIP: Covering + unique indexes.

As far I can see, there is no any on-disk representation differece for *existing* indexes. So, pg_upgrade is not need here and there isn't any new code to support "on-fly" modification. Am I right? -- Teodor Sigaev E-mail: teo...

Re: WIP: Covering + unique indexes.

code doesn't just confuse things (e.g. see recent commit 2a67d644). It also seems like it could actually be harmful. This is code that could only ever corrupt your database. I'm fine if Teodor wants to commit that change separately, of course. -- Teodor Sigaev

Re: pgindent run soon?

If there are large refactoring or bug-fix patches that haven't landed yet, then it'd be appropriate to wait for those to get in, but I'm not aware of such at the moment. Pls, wait https://www.postgresql.org/message-id/9c63951d-7696-ecbb-b832-70db7ed3f39b%40sigaev.ru Thank you. -- Teodor

Re: WIP: Covering + unique indexes.

was unclear. Attached patch contains all changes suggested in my previous email. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ diff --git a/contrib/amcheck/verify_nbtree.c b/contrib/amcheck/verify_nbtree.c index

Re: WIP: Covering + unique indexes.

: + /* +*Cannot leak memory here, TupleDescCopy() doesn't allocate any +* inner structure, so, plain pfree() should clean all allocated memory +*/ fixed -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Corrupted btree index on HEAD because of covering indexes

he culprit (8224de4). Thanks, -- Michael -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: WIP: Covering + unique indexes.

Thank you, pushed Peter Geoghegan wrote: On Wed, Apr 18, 2018 at 10:47 PM, Teodor Sigaev <teo...@sigaev.ru> wrote: Thank you, pushed. Thanks. I saw another preexisting issue, this time one that has been around since 2007. Commit bc292937 forgot to remove a comment above _bt_inse

Re: Corrupted btree index on HEAD because of covering indexes

, which makes a bit more sense. Hm, it seems to me, that 350ms is short enough to place it in both core and amcheck test. I think, basic functionality should be covered by core tests as we test insert/create. -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: Corrupted btree index on HEAD because of covering indexes

-engineering -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Corrupted btree index on HEAD because of covering indexes

regression test coverage here. Will try to invent not so large test. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Corrupted btree index on HEAD because of covering indexes

decisions are follows, I didn't look at that. Trivial and naive fix is attached, but for me it looks a bit annoing that we store pointer (leafhikey) somewhere inside unlocked page. -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: Corrupted btree index on HEAD because of covering indexes

deletion. This removes last naked usage of ItemPointer(SetInvalid/IsInvalid/GetBlockNumberNoCheck) and uses self-described macroses. Patch is attached. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http

  1   2   >