[COMMITTERS] pgsql: Remove dead stuff from pgcrypto.
Remove dead stuff from pgcrypto. pgp-pubkey-DISABLED test has been unused since 2006, when support for built-in bignum math was added (commit 1abf76e8). pgp-encrypt-DISABLED has been unused forever, AFAICS. Also remove a couple of unused error codes. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/b2cc748b09456ea24cdd00a7691ce33db9a1af45 Modified Files -- contrib/pgcrypto/expected/pgp-encrypt-DISABLED.out | 1 - contrib/pgcrypto/expected/pgp-pubkey-DISABLED.out | 1 - contrib/pgcrypto/px.c | 4 contrib/pgcrypto/px.h | 4 ++-- contrib/pgcrypto/sql/pgp-encrypt-DISABLED.sql | 1 - contrib/pgcrypto/sql/pgp-pubkey-DISABLED.sql | 1 - 6 files changed, 2 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Rewrite the perl scripts to produce our Unicode conversion table
Rewrite the perl scripts to produce our Unicode conversion tables. Generate EUC_CN mappings from gb-18030-2000.xml, because GB2312.TXT is no longer available. Get UHC from windows-949-2000.xml, it's more up-to-date. Plus tons more small changes. With these changes, the perl scripts faithfully produce the *.map files we have in the repository, from the external source files. In the passing, fix the Makefile to also download CP932.TXT and CP950.TXT. Based on patches by Kyotaro Horiguchi, reviewed by Daniel Gustafsson. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/1de9cc0dcca649d1900720924f4ea5c430d1a51e Modified Files -- src/backend/utils/mb/Unicode/Makefile | 22 +- src/backend/utils/mb/Unicode/UCS_to_BIG5.pl| 184 ++ src/backend/utils/mb/Unicode/UCS_to_EUC_CN.pl | 154 +++- .../utils/mb/Unicode/UCS_to_EUC_JIS_2004.pl| 272 +- src/backend/utils/mb/Unicode/UCS_to_EUC_JP.pl | 398 + src/backend/utils/mb/Unicode/UCS_to_EUC_KR.pl | 115 +- src/backend/utils/mb/Unicode/UCS_to_EUC_TW.pl | 142 ++-- src/backend/utils/mb/Unicode/UCS_to_GB18030.pl | 80 + src/backend/utils/mb/Unicode/UCS_to_JOHAB.pl | 31 ++ .../utils/mb/Unicode/UCS_to_SHIFT_JIS_2004.pl | 205 ++- src/backend/utils/mb/Unicode/UCS_to_SJIS.pl| 157 ++-- src/backend/utils/mb/Unicode/UCS_to_UHC.pl | 51 +++ src/backend/utils/mb/Unicode/UCS_to_most.pl| 116 +- src/backend/utils/mb/Unicode/convutils.pm | 282 +++ .../utils/mb/Unicode/euc_jis_2004_to_utf8.map | 9 +- .../mb/Unicode/euc_jis_2004_to_utf8_combined.map | 7 +- src/backend/utils/mb/Unicode/euc_jp_to_utf8.map| 4 +- src/backend/utils/mb/Unicode/euc_kr_to_utf8.map| 2 + src/backend/utils/mb/Unicode/johab_to_utf8.map | 2 + .../utils/mb/Unicode/shift_jis_2004_to_utf8.map| 9 +- .../mb/Unicode/shift_jis_2004_to_utf8_combined.map | 7 +- src/backend/utils/mb/Unicode/ucs2utf.pl| 35 -- src/backend/utils/mb/Unicode/uhc_to_utf8.map | 2 + src/backend/utils/mb/Unicode/utf8_to_euc_cn.map| 2 + .../utils/mb/Unicode/utf8_to_euc_jis_2004.map | 9 +- .../mb/Unicode/utf8_to_euc_jis_2004_combined.map | 7 +- src/backend/utils/mb/Unicode/utf8_to_euc_jp.map| 2 + src/backend/utils/mb/Unicode/utf8_to_euc_kr.map| 2 + src/backend/utils/mb/Unicode/utf8_to_johab.map | 2 + .../utils/mb/Unicode/utf8_to_shift_jis_2004.map| 9 +- .../mb/Unicode/utf8_to_shift_jis_2004_combined.map | 7 +- src/backend/utils/mb/Unicode/utf8_to_sjis.map | 4 +- src/backend/utils/mb/Unicode/utf8_to_uhc.map | 2 + 33 files changed, 791 insertions(+), 1541 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Remove leading zeros, for consistency with other map files.
Remove leading zeros, for consistency with other map files. The common style is to pad to 4 digits. Running the current perl scripts to generate these map files would override this change, but the next commit will rewrite the perl scripts to produce this style. I'm doing this as a separate commit, to make it more clear what non-cosmetic changes the next commit makes to the map files. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/6c303223be34329bae2f03a87590ffa0742a65f6 Modified Files -- .../utils/mb/Unicode/euc_jis_2004_to_utf8.map | 22052 +- .../mb/Unicode/euc_jis_2004_to_utf8_combined.map |50 +- .../utils/mb/Unicode/shift_jis_2004_to_utf8.map| 21936 +- .../utils/mb/Unicode/utf8_to_euc_jis_2004.map | 22052 +- .../mb/Unicode/utf8_to_euc_jis_2004_combined.map |50 +- .../utils/mb/Unicode/utf8_to_shift_jis_2004.map| 22542 +-- 6 files changed, 44341 insertions(+), 44341 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Remove code points < 0x80 from character conversion tables.
Remove code points < 0x80 from character conversion tables. PostgreSQL treats characters with < 0x80 leading byte as plain ASCII, and they are not even passed to the conversion routines. There is no point in having them in the conversion tables. Everything in the tables were direct ASCII-ASCII mappings, except for two: * SHIFT_JIS_2004 code point 0x5C (backslash in ASCII) was mapped to Unicode YEN SIGN character. * Unicode 0x5C (backslash again) was mapped to "REVERSE SOLIDUS" in SHIFT_JIS_2004 These mappings never had any effect, so there's no functional change from removing them. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/2c09c93ce1b80a417b7c372c43f5089c0d691749 Modified Files -- .../utils/mb/Unicode/euc_jis_2004_to_utf8.map | 128 - .../utils/mb/Unicode/shift_jis_2004_to_utf8.map| 128 - .../utils/mb/Unicode/utf8_to_euc_jis_2004.map | 128 - .../utils/mb/Unicode/utf8_to_shift_jis_2004.map| 128 - 4 files changed, 512 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: doc: Fix typo
doc: Fix typo From: Tsunakawa, Takayuki Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/2f0c7ff48b68b6fb6dc373ffcebd99343a9f6451 Modified Files -- doc/src/sgml/config.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: doc: Remove claim about large shared_buffers on Windows
doc: Remove claim about large shared_buffers on Windows Testing has shown that it is no longer correct. From: Tsunakawa, Takayuki Reviewed-by: amul sul Discussion: http://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1F5EE995@G01JPEXMBYT05/ Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/81c52728f82be5303ea16508255e948017f4cd87 Modified Files -- doc/src/sgml/config.sgml | 5 - 1 file changed, 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make all unicode perl scripts to use strict, rearrange logic for
Make all unicode perl scripts to use strict, rearrange logic for clarity. The loops were a bit difficult to understand, due to breaking out of them early. Also fix things that perlcritic complained about. Daniel Gustafsson Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/021d254d9aa0a26a2f6e8cecd922024e65be93a0 Modified Files -- src/backend/utils/mb/Unicode/UCS_to_BIG5.pl| 4 +- src/backend/utils/mb/Unicode/UCS_to_EUC_CN.pl | 18 ++--- .../utils/mb/Unicode/UCS_to_EUC_JIS_2004.pl| 44 +--- src/backend/utils/mb/Unicode/UCS_to_EUC_JP.pl | 2 +- src/backend/utils/mb/Unicode/UCS_to_EUC_KR.pl | 3 +- src/backend/utils/mb/Unicode/UCS_to_EUC_TW.pl | 3 +- src/backend/utils/mb/Unicode/UCS_to_GB18030.pl | 18 ++--- src/backend/utils/mb/Unicode/UCS_to_JOHAB.pl | 3 +- .../utils/mb/Unicode/UCS_to_SHIFT_JIS_2004.pl | 83 ++ src/backend/utils/mb/Unicode/UCS_to_SJIS.pl| 2 +- src/backend/utils/mb/Unicode/UCS_to_UHC.pl | 18 ++--- src/backend/utils/mb/Unicode/UCS_to_most.pl| 12 ++-- 12 files changed, 102 insertions(+), 108 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Doc: improve description of trim() and related functions.
Doc: improve description of trim() and related functions. Per bug #14441 from Mark Pether, the documentation could be misread, mainly because some of the examples failed to show what happens with a multicharacter "characters to trim" string. Also, while the text description in most of these entries was fairly clear that the "characters" argument is a set of characters not a substring to match, some of them used variant wording that was a bit less clear. trim() itself suffered from both deficiencies and was thus pretty misinterpretable. Also fix failure to explain which of LEADING/TRAILING/BOTH is the default. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/dd3edfe630fecd561568455a2c47ec5858a95e8c Modified Files -- doc/src/sgml/func.sgml | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Doc: improve description of trim() and related functions.
Doc: improve description of trim() and related functions. Per bug #14441 from Mark Pether, the documentation could be misread, mainly because some of the examples failed to show what happens with a multicharacter "characters to trim" string. Also, while the text description in most of these entries was fairly clear that the "characters" argument is a set of characters not a substring to match, some of them used variant wording that was a bit less clear. trim() itself suffered from both deficiencies and was thus pretty misinterpretable. Also fix failure to explain which of LEADING/TRAILING/BOTH is the default. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/3e65fd045a924f4c4cfaa0f73857db28558afd11 Modified Files -- doc/src/sgml/func.sgml | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Doc: improve description of trim() and related functions.
Doc: improve description of trim() and related functions. Per bug #14441 from Mark Pether, the documentation could be misread, mainly because some of the examples failed to show what happens with a multicharacter "characters to trim" string. Also, while the text description in most of these entries was fairly clear that the "characters" argument is a set of characters not a substring to match, some of them used variant wording that was a bit less clear. trim() itself suffered from both deficiencies and was thus pretty misinterpretable. Also fix failure to explain which of LEADING/TRAILING/BOTH is the default. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/bb389ad8cdda3756b93e06a532128c5b34307673 Modified Files -- doc/src/sgml/func.sgml | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Doc: improve description of trim() and related functions.
Doc: improve description of trim() and related functions. Per bug #14441 from Mark Pether, the documentation could be misread, mainly because some of the examples failed to show what happens with a multicharacter "characters to trim" string. Also, while the text description in most of these entries was fairly clear that the "characters" argument is a set of characters not a substring to match, some of them used variant wording that was a bit less clear. trim() itself suffered from both deficiencies and was thus pretty misinterpretable. Also fix failure to explain which of LEADING/TRAILING/BOTH is the default. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/35532e3b0a96345d230893cb18cb9590cdef142c Modified Files -- doc/src/sgml/func.sgml | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Doc: improve description of trim() and related functions.
Doc: improve description of trim() and related functions. Per bug #14441 from Mark Pether, the documentation could be misread, mainly because some of the examples failed to show what happens with a multicharacter "characters to trim" string. Also, while the text description in most of these entries was fairly clear that the "characters" argument is a set of characters not a substring to match, some of them used variant wording that was a bit less clear. trim() itself suffered from both deficiencies and was thus pretty misinterpretable. Also fix failure to explain which of LEADING/TRAILING/BOTH is the default. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/213c0f2d7880f78c710127920cf4bf7017e0fa57 Modified Files -- doc/src/sgml/func.sgml | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Doc: improve description of trim() and related functions.
Doc: improve description of trim() and related functions. Per bug #14441 from Mark Pether, the documentation could be misread, mainly because some of the examples failed to show what happens with a multicharacter "characters to trim" string. Also, while the text description in most of these entries was fairly clear that the "characters" argument is a set of characters not a substring to match, some of them used variant wording that was a bit less clear. trim() itself suffered from both deficiencies and was thus pretty misinterpretable. Also fix failure to explain which of LEADING/TRAILING/BOTH is the default. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/523bb1de834e9c05fec0f0d85330cfa15a3000b7 Modified Files -- doc/src/sgml/func.sgml | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve hash index bucket split behavior.
Improve hash index bucket split behavior. Previously, the right to split a bucket was represented by a heavyweight lock on the page number of the primary bucket page. Unfortunately, this meant that every scan needed to take a heavyweight lock on that bucket also, which was bad for concurrency. Instead, use a cleanup lock on the primary bucket page to indicate the right to begin a split, so that scans only need to retain a pin on that page, which is they would have to acquire anyway, and which is also much cheaper. In addition to reducing the locking cost, this also avoids locking out scans and inserts for the entire lifetime of the split: while the new bucket is being populated with copies of the appropriate tuples from the old bucket, scans and inserts can happen in parallel. There are minor concurrency improvements for vacuum operations as well, though the situation there is still far from ideal. This patch also removes the unworldly assumption that a split will never be interrupted. With the new code, a split is done in a series of small steps and the system can pick up where it left off if it is interrupted prior to completion. While this patch does not itself add write-ahead logging for hash indexes, it is clearly a necessary first step, since one of the things that could interrupt a split is the removal of electrical power from the machine performing it. Amit Kapila. I wrote the original design on which this patch is based, and did a good bit of work on the comments and README through multiple rounds of review, but all of the code is Amit's. Also reviewed by Jesper Pedersen, Jeff Janes, and others. Discussion: http://postgr.es/m/caa4ek1lfzczyxloxs874ad0+s-zm60u9bwcyiuzx9mhz-kc...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/6d46f4783efe457f74816a75173eb23ed8930020 Modified Files -- src/backend/access/hash/Makefile | 4 +- src/backend/access/hash/README| 311 +++- src/backend/access/hash/hash.c| 350 +++--- src/backend/access/hash/hashinsert.c | 86 -- src/backend/access/hash/hashovfl.c| 154 ++ src/backend/access/hash/hashpage.c| 527 +++--- src/backend/access/hash/hashscan.c| 153 -- src/backend/access/hash/hashsearch.c | 225 +-- src/backend/access/hash/hashutil.c| 94 ++ src/backend/utils/resowner/resowner.c | 3 - src/include/access/hash.h | 82 -- src/include/access/itup.h | 2 +- 12 files changed, 1365 insertions(+), 626 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Perform one only projection to compute agg arguments.
Perform one only projection to compute agg arguments. Previously we did a ExecProject() for each individual aggregate argument. That turned out to be a performance bottleneck in queries with multiple aggregates. Doing all the argument computations in one ExecProject() is quite a bit cheaper because ExecProject's fastpath can do the work at once in a relatively tight loop, and because it can get all the required columns with a single slot_getsomeattr and save some other redundant setup costs. Author: Andres Freund Reviewed-By: Heikki Linnakangas Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8ed3f11bb045ad7a3607690be668dbd5b3cc31d7 Modified Files -- src/backend/executor/nodeAgg.c | 167 - src/include/nodes/execnodes.h | 4 + 2 files changed, 119 insertions(+), 52 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: User narrower representative tuples in the hash-agg hashtable.
User narrower representative tuples in the hash-agg hashtable. So far the hashtable stored representative tuples in the form of its input slot, with all columns in the hashtable that are not needed (i.e. not grouped upon or functionally dependent) set to NULL. Thats good for saving memory, but it turns out that having tuples full of NULL isn't free. slot_deform_tuple is faster if there's no NULL bitmap even if no NULLs are encountered, and skipping over leading NULLs isn't free. So compute a separate tuple descriptor that only contains the needed columns. As columns have already been moved in/out the slot for the hashtable that does not imply additional per-row overhead. Author: Andres Freund Reviewed-By: Heikki Linnakangas Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/fc4b3dea2950e4f6081f1ed2380f82c9efd672e0 Modified Files -- src/backend/executor/nodeAgg.c | 164 +++-- src/include/nodes/execnodes.h | 5 +- 2 files changed, 112 insertions(+), 57 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
