It's not clear from the web site in question that the relevant code is
released under the PostgreSQL license.
As author I allow to use this code in PostgreSQL and under its license.
--
Teodor Sigaev E-mail: teo...@siga
WLockPadded *) ShmemAlloc(sizeof(LWLockPadded) *
nslots);
Attached patch fixes that by removing extra ShmemAlloc for SLRU.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Teodor Sigaev
frz->t_infomask &= HEAP_XMAX_COMMITTED;
Seems, in last line it should be a bitwise OR instead of AND. Now this line
cleans all bits in t_infomask which later will be copied directly in tuple.
--
Teodor Sigaev
dexes use it as opaque
type. Except, at least, btree and GiST - they believ that internal pointers are
the same as outer (to heap)
Another dubious part - BitmapScan.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
BTW, was the larger query plan that you showed (with a Materialize node)
generated by 9.6, or v10 HEAD? Because I would be surprised if 9.6 did
v10,
commit acbd8375e954774181b673a31b814e9d46f436a5
Author: Magnus Hagander
Date: Fri Jun 2 11:18:24 2017 +0200
--
Teodor Sigaev
There were old threads about considering a risk factor when estimating
plans, and I'm thinking this issue is the planner failing to do
exactly that.
I'm afraid it's tool late for v10
--
Teodor Sigaev E-mail: t
Teodor, could you check if this patch fixes your real-world problem?
It works fine with original query, thank you. But some other query slowdowns for
~10% (9 secs vs 10 secs). Look at following part of plans of huge query:
without patch:
-> Nested Loop (cost=34.82..50.91 rows=1 width
come from a real
world case? else, how did you stumble upon it?
Unfortunately, it's taken from real application.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql
ize (cost=0.00..1.40 rows=1 width=8) (actual time=0.000..0.001
rows=17 loops=1048576)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
Timing is on.
DROP TABLE
Time: 5,268 ms
SELECT 32
T
development
and should wait for v11. Opinions?
Obviously, I'm voting for second patch applied to version 10.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers
Ah, thanks for the clue about enable_hashjoin, because it wasn't
reproducing for me as stated.
I missed tweaked config, sorry
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers ma
Both 9.6 and 10devel are affected to addiction of query result on seqscan
variable.
Oops, I was too nervious, 9.6 is not affected to enable_seqscan setting. But it
doesn't push down condition too.
--
Teodor Sigaev E-mail: teo...@siga
ult on seqscan variable.
Dump to reproduce (subset of real data but obfucated), queries are in attachment
http://sigaev.ru/misc/exists_to_nested.sql.gz
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sig
both patches?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
0001-covering-core.patch
Description: binary/octet-stream
0002-covering-btree.patch
Description: binary/octet-stream
--
Sen
this thread about naming and both databases, which
support covering indexes, use INCLUDE keyword.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql
Thank you, pushed
Excellent! I've attached a new (and hopefully final)
version of the patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (
to tab-complete.c that
is a shame I didn't do it before, very sorry about that.
Attached the new version of the patch that is basically the same as previously
with the addition to tab completion for psql and rebased with master.
Hope it is enough. Thank you all.
--
Matheus de Oliveira
Thank you, pushed
Michael Paquier wrote:
On Fri, Mar 24, 2017 at 11:36 PM, Teodor Sigaev wrote:
And the renaming of pg_clog to pg_xact is also my fault. Attached is
an updated patch.
Thank you. One more question: what about symlinks? If DBA moves, for
example, pg_xact to another dist and
.
If something should be done in this area, that would be surely in
fsync_fname directly to centralize all the calls, and I would think of
that as a separate patch, and a separate discussion.
Agree
--
Teodor Sigaev E-mail: teo...@sigaev.ru
No, it is really needed so that the lag measure is correct.
Thank you, pushed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Sorry, 1) and 4) is my fault, comment in hsearch.h:
* ... The hash key
* is expected to be at the start of the caller's hash entry data structure.
Ops, forgot that.
Teodor Sigaev wrote:
things in order I'm attaching the previous patch as well.
Patches look good, but I have some n
free from point of view of pgStatTabList.
4 step 2. The same as 1) about SeenRelsEntry->rel_id but it even isn't
initialized anywhere.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.
.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Thank you all, pushed
Michael Paquier wrote:
On Fri, Mar 24, 2017 at 1:45 AM, Teodor Sigaev wrote:
I believe patch looks good and it's ready to commit.
Thanks for the review!
As I understand, it fixes bug introduced by
commit 7117685461af50f50c03f43e6a622284c8d54694
Date: Tue Apr
g = false;
- st->is_throttled = false;
memset(st->prepared, 0, sizeof(st->prepared));
}
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing l
Hmm, it doesn't work (but appplies) on current HEAD:
% uname -a
FreeBSD *** 11.0-RELEASE-p8 FreeBSD 11.0-RELEASE-p8 #0 r315651: Tue Mar 21
02:44:23 MSK 2017 teodor@***:/usr/obj/usr/src/sys/XOR amd64
% pg_config --configure
'--enable-depend' '--enable-cassert' &
ed to 9.6?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Thank you, pushed
Andrew Borodin wrote:
2017-03-22 22:48 GMT+05:00 Teodor Sigaev :
hasEmptyChild? and hasNonEmptyChild (BTW, isAnyNonempy has missed 't')
Yes, I think this naming is good. It's clear what's in common in these
flags and what's different.
And if
EmptyChild? and hasNonEmptyChild (BTW, isAnyNonempy has missed 't')
And if the whole posting tree is empty,then we could mark root page as leaf and
remove all other pages in tree without any locking. Although, it could be a task
for separate patch.
--
Teodor Sigaev
but isn't better to have another
protection? Like WAL-logging of WAL segment removing...
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-h
om
ginVacuumPostingTree() and patch should just remove lock for cleanup over
ginVacuumPostingTreeLeaves() and if it returns that tree contains empty page
then lock the whole posting tree to do ginScanToDelete() work.
--
Teodor Sigaev
:not tested
As I can see, this bugfix was already discussed and reviewed.
All mentioned issues are fixed in the latest version of the patch
So I mark it "Ready for committer".
Thank you for fixing it!
The new status of this patch is: Ready for Committer
--
Teo
paranoic and do this same way as before. Revised patch is
attached.
I see the change was done in 9.6 release cycle in commit
48354581a49c30f5757c203415aa8412d85b0f70 at April, 10. Does it mean the fix
should be backpatched too?
--
Teodor Sigaev
PING FOR asciiword WITH xx,
english_stem;
# select to_tsvector('english', 'bookings');
to_tsvector
--
'book':1 'booking':1
# select to_tsvector('english', 'bookings') @@ '
Please find attached a patch which makes it possible to disallow
UPDATEs and DELETEs which lack a WHERE clause. As this changes query
behavior, I've made the new GUCs PGC_SUSET.
What say?
DELETE FROM tbl WHERE true; ?
--
Teodor Sigaev E-mail
ms, so care must be taken.
To see memory allocation by opinion of pgsql it's possible to use
https://github.com/postgrespro/memstat
This module (9.6+) could collect information about MemoryContexts allocation.
--
Teodor Sigaev E-mail: teo..
The above-described topic is currently a PostgreSQL 9.6 open item. Teodor,
I'm working on it now and believe that fix will be published today.
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not b
That didn't cover all the places that needed to be fixed, but I have
re-read the docs and believe I've made things good now.
I have reviewed this thread and verified that all the cases raised in it
now work as desired, so I have marked the open item closed.
Thank you very much!
Attached patch changes a precedences of operations to |, &, <->, | in ascending
order. BTW, it simplifies a bit a code around printing and parsing of tsquery.
|, &, <->, ! of course
--
Teodor Sigaev E-ma
;->
operators appeared in situation when <-> degenerates to & in case of
absence of positional information. Looks like we mixed different
things, will fix.
Attached patch changes a precedences of operations to |, &, <->, | in ascending
order. BTW, it simplifies a bit a code arou
We're really quickly running out of time to get this done before
beta2. Please don't commit anything that's going to break the tree
because we only have about 72 hours before the wrap, but if it's
correct then it should go in.
Isn't late now? Or wait to beta2
not quite as easy as I was thinking. I'm
okay with the patch as presented.
Huh, I found that my isn't correct for example which I show :(. Reworked patch
is in attach.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Tom Lane wrote:
Teodor Sigaev writes:
So I think there's a reasonable case for decreeing that should only
match lexemes *exactly* N apart. If we did that, we would no longer have
the misbehavior that Jean-Pierre is complaining about, and we'd not need
to argue about whether <0
on
information. If this behavior looks more reasonable, I'll commit that.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
phrase_no_fallback.patch
Description: binary/octet-stream
to_tsvector
-----
'bar':3 'foo':2 'foo-bar':1
# select phraseto_tsquery('foo-bar');
phraseto_tsquery
---
( 'foo-bar' <-> 'foo' ) <-> 'bar'
and
management team
ownership without further notice.
[1]
http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com
I'm working on it right now.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW:
he in-core ones.
+1.
Are there other opinions? That's not a 9.6 blocker IMO, so I could get
patches out for 10.0 if needed.
I missed that on review process, but I'm agree it should be implemented.
--
Teodor Sigaev E-mail: t
;
uint32 eas_used;
RBTree *tree;
Are you sure this is safe, Teodor? I don't have time to study the
patch in detail, but offhand I think that it might have been better to
make allocatedMemory of type int64, just like the tuplesort.c memory
accounting variables are post-MaxAllocHuge.
This all should me moved behind "access method" abstraction...
+1 relopt_kind should be moved in am, at least. Or removed.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
-
you should add "USING bloom" to the insert statement, in order make this
example work.
Patch in the attachment fixes an example. Please commit it ;-)
Thank you, applied
--
Teodor Sigaev E-mail: teo...
');
does it as you wish
I realize we're already in beta, but pgCon was actually the first time I
saw the new syntax. I think if we don't do this now, we'll be doing it
for 10.0.
Havn't an objections for 10.0
--
Teodor Sigaev E-mail: teo...@sig
uildfarm.org/cgi-bin/show_log.pl?nm=curculio&dt=2016-05-17+19%3A30%3A09
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
27;t
check that.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
bug (first ERROR: attempted to delete invisible tuple). IMHO, it's
a separate bug, not related to oid. Unfortunately, I've never seen such error on
my notebook.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Hm. And you're not seeing the asserts I reported in
http://archives.postgresql.org/message-id/20160505185246.2i7qftadwhzewykj%40alap3.anarazel.de
?
I see it a lot, but I think that is a result of ereport(FATAL) after
FileWrite(BLCKSZ/3) added by Jeff.
Teodor S
2
#19 0x008e54bd in exec_bind_message (input_message=0x7fffdf60) at
postgres.c:1602
#20 0x008e3957 in PostgresMain (argc=1, argv=0x801d3c968,
dbname=0x801d3c948 "teodor", username=0x801d3c928 "teodor") at postgres.c:4105
#21 0x00839744 in Backend
, but it could take a time.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
16424
The test required 10 hours to run on my notebook. postgresql was compiled with
-O0 --enable-debug --enable-cassert.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pg
Thank you, pushed.
Stas Kelvich wrote:
Hi.
As discovered by Oleg Bartunov, current filter() function for tsvector can
crash backend.
Bug was caused erroneous usage of char type in memmove argument.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
I think this number should be specified only once, in .h file.
Yep, that sounds true.
It may be a good idea to make something similar for contrib/bloom if >
0 values are defined for amstrategies or amsupport for consistency.
Thank you, pushed.
--
Teodor Sig
tabase with OID 16384
I've pushed v5 of gin-alone-cleanup patch, many thanks to all participants.
Will work on backpatch
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-
There are some previously unnoticed errors in docs (master branch), this patch
fixes them.
Thank you, pushed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers
acuum and gin_clean_pending_list() should do that. In all other cases it should
stop early to prevent possible infinite cleanup. Patch attached.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.siga
en we read page which was a tail on cleanup
start then we sets cleanupFinish variable and after cleaning that page we will
stop further cleanup. Any insert caused during cleanup will be placed after
blknoFinish (corner case: in that page), so, vacuum should not miss tuples
marked as de
it at mondeay and backpatch all supported
versions.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
nd. I
think that would probably be good enough, because the current
throttling behavior is purely accidentally and doesn't *guarantee* a
limit on the size of the pending list.
Added, see attached patch (based on v3.1)
--
Teodor Sigaev
known
Yes
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
I agree with both of these ideas. Patch is attached.
Hmm, you accidentally forget to change flag type of GenericXLogRegister in
contrib/bloom signature.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http
BloomPageOpaqueData struct equals 6 bytes but special size is MAXALIGNED, so,
last two bytes will be unused. If unused field is not a problem, I will push
this patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Thank you very much
thank you, pushed. Pls, pay attention to buildfarm.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
strictly less
than indnatts, pls, change assertion. If they are equal the this function
becomes complicated variant of CopyIndexTuple()
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
nding lock patch, it doesn't change an internal logic of lock machinery.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
re is a new version of patch (it will throw
an error for an existing key). Is it better now?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pg
ression test for it.
I'm agree about covering this case by tests, but I think it should be allowed.
In this case it will work exactly as jsbonb_set
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.s
It seems to me that the patch is completed.
Except, maybe, grammar check of comments and documentation.
Looking forward to your review.
Are there any objectins on it? I'm planning to look closely today or tommorrow
and commit it.
--
Teodor Sigaev E-mail
The above-described topic is currently a PostgreSQL 9.6 open item. Teodor,
since you committed the patch believed to have created it, you own this open
item. If that responsibility lies elsewhere, please let us know whose
responsibility it is to fix this. Since new open items may be discovered
gex, any number of tokens. And it saves rules
about duplicating character.
select 'fat'::tsquery ** 'cat';
select 'fat * cat'::tsquery;
select 'fat * [3] cat'::tsqyery; -- for non-default distance.
--
Teodor Sigaev
urrounding
words form a phrase. It seems much more natural to me.
Yes, agree for omission. But for reason above its'n a good name although I don't
have a strong objections.
may be <=>? it isn't used anywhere yet.
select 'fat'::tsquery <=> 'cat';
sele
y (besides myself) has gone so far yet.
On 25.03.16 18:42 MSK, David Steele wrote:
Time is short and it's not encouraging that you say there is "still much
work to be done".
Indeed, I was inaccurate. I am more than interested in the positive outcome.
--
Teodor Sigaev
ssing and also added support for
them. It is also attached with the updated version of my test script.
I hope I haven't changed the patch too much. I have also pushed the
changes here:
https://github.com/hasegeli/postgres/commits/box-spgist
--
Teodor Sigaev
cussion is about SQL-level types which could be stored on disk, not
about in-memory structs
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgs
ful example for such feature.
- add callback via RegisterResourceReleaseCallback() which will cleanup state
of genericXlogStatus variable
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Se
I incorporated your changes and did some additional refinements on top of them
still.
Attached is delta against v12, that should cause less issues when merging for
Teodor.
But last version is 13th?
BTW, it would be cool to add odcs in VII. Internals chapter, description should
be similar to
src/backend/access/transam/generic_xlog.c...)
Patching file src/backend/access/transam/generic_xlog.c using Plan A...
patch: malformed patch at line 634: diff --git
a/src/backend/access/transam/rmgr.c b/src/backend/access/transam/rmgr.c
--
Teodor Sigaev E-mail
Does that mean this patch should be closed or is there more remaining to commit?
Petr promises to check english in comments/docs in generic-wal patch at this
week, bloom patch depends on it. Bloom patch is ready from my point of view.
--
Teodor Sigaev E
t for libicu with configure flag
--with-icu. Patch rebased to current HEAD, hope, it works.
It's based on https://people.freebsd.org/~girgen/postgresql-icu/readme.html
work, and it was migrated to 9.5 with abbrevation keys support.
Patch in current state is not ready to commit, of course.
in->allTheSame)
Most of the things happening before this check is not used in there.
Shouldn't we move this to the top of the function?
yep, fixed
+ out->nodeNumbers = (int *) palloc(sizeof(int) * in->nNodes);
This could go before allThe
help GiST. See Oleg's message.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
tend to think of a *point* as having *zero* dimensions. Would it
perhaps be more accurate to say we are treating a 2-dimensional box
as a point in 4-dimensional space?
Exactly, sorry for ambiguity.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
DatumGetBoxP(in->scankeys[i].sk_argument),
+p_query_rect
+);
I don't think this matches the project coding style.
fixed
+ int flag = 1,
Wouldn't it be better as "bool"?
fixed.
The regress
ut I won't get to it before weekend.
So, per patch status:
create-am
ready
generic-xlog
need to fix comments/docs
bloom-contrib
need review. I'm an original author of this module and of course
I can do some review of it but, seems, it's
ion has none.
added
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
0001-idx_or_core-v4.patch.gz
Description: GNU Zip compressed data
0002-idx_or_indexes-v4.patch.gz
Description: GNU Zip compresse
nges how 'width' is computed.
fixed too
So I think this way of building the index path from a BitmapOr path is
pretty much a dead-end.
I don't think so because separate code path to support OR-clause in index will
significanlty duplicate BitmapOr gene
Good catch, thanks! Tests were added.
I don't see any objection, is consensus reached? I'm close to comiit that...
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent
because they are presented in auto-generated file
./src/include/utils/builtins.h
range patch is unchanged, but still attached to keep them altogether.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.si
I hope so the messages are ok now. Few more regress tests added.
Thank you, committed.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql
ROR: identifier contains disallowed characters: "\"c"
Error message wrongly points to the reason of error.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
parse_ident-13.patch
De
I saw errors on windows, here is the fix:
Thank you, pushed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
vector and
tsvector_to_array to have consistent name. Later we could add
to_tsvector([regconfig, ], text[]) with morphological processing.
Thoughts?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www
One more inconsistence:
# select parse_ident(E'"\005"') as "\005";
\005
{\x05}
Display outputs of actual identifier and parse_indent are differ.
Actually, I can live with both but are any other opinions? Seems, at least
difference of actual identifier and outpu
1 - 100 of 835 matches
Mail list logo
