Re: [COMMITTERS] pgsql: Default monitoring roles
On 2017-03-30 20:20, Simon Riggs wrote: Default monitoring roles The buildfarm is showing red (the same errors that I get...): pgrowlocks.c: In function ‘pgrowlocks’: pgrowlocks.c:105:65: error: expected ‘)’ before ‘;’ token is_member_of_role(GetUserId(), DEFAULT_ROLE_STAT_SCAN_TABLES); ^ [...] -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Build HTML documentation using XSLT stylesheets by default
On 2016-11-16 08:06, Peter Eisentraut wrote: Build HTML documentation using XSLT stylesheets by default The old DSSSL build is still available for a while using the make target "oldhtml". This xslt build takes 8+ minutes, compared to barely 1 minute for 'oldhtml'. I'd say that is a strong disadvantage. I hope 'for a while' will mean 'for a long time to come' or even 'forever.' Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: doc: requirepeer is a way to avoid spoofing
On 2016-08-19 03:42, Bruce Momjian wrote: + On way to prevent spoofing of typo: 'On way to ' should be 'One way to' Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Bloom index contrib module
On 2016-04-01 14:36, Erik Rijkers wrote: On 2016-04-01 15:49, Teodor Sigaev wrote: Bloom index contrib module doc/src/sgml/bloom.sgml | 218 ++ The size of example table (in bloom.sgml): CREATE TABLE tbloom AS SELECT random()::int as i1, random()::int as i2, [...] random()::int as i12, random()::int as i13 FROM generate_series(1,1000); seems too small to demonstrate the index-use. For me, both on $BigServer at work as on $ModestDesktop at home the 1000 rows are not enough. I suggest making the rowcount in that example a larger, for instance 1, so: generate_series(1,1). Does that make sense? I realize the behavior is probably somewhat dependent from hardware and settings... thanks, Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Bloom index contrib module
On 2016-04-01 15:49, Teodor Sigaev wrote: Bloom index contrib module Module provides new access method. It is actually a simple Bloom filter implemented as pgsql's index. It could give some benefits on search with large number of columns. doc/src/sgml/bloom.sgml | 218 ++ I edited the bloom.sgml text a bit. Great stuff, thanks! Erik Rijkers --- doc/src/sgml/bloom.sgml.orig 2016-04-01 16:03:29.0 +0200 +++ doc/src/sgml/bloom.sgml 2016-04-01 16:30:34.0 +0200 @@ -8,31 +8,31 @@ - bloom is a contrib which implements index access method. It comes - as example of custom access methods and generic WAL records usage. But it - is also useful itself. + bloom is a module which implements an index access method. It comes + as an example of custom access methods and generic WAL records usage. But it + is also useful in itself. Introduction - Implementation of + The implementation of a http://en.wikipedia.org/wiki/Bloom_filter;>Bloom filter - allows fast exclusion of non-candidate tuples. - Since signature is a lossy representation of all indexed attributes, - search results should be rechecked using heap information. - User can specify signature length (in uint16, default is 5) and the number of - bits, which can be setted, per attribute (1 < colN < 2048). + allows fast exclusion of non-candidate tuples via signatures. + Since a signature is a lossy representation of all indexed attributes, + search results must be rechecked using heap information. + The user can specify signature length (in uint16, default is 5) and the number of + bits, which can be set per attribute (1 < colN < 2048). - This index is useful if table has many attributes and queries can include - their arbitary combinations. Traditional btree index is faster - than bloom index, but it'd require too many indexes to support all possible - queries, while one need only one bloom index. Bloom index supports only - equality comparison. Since it's a signature file, not a tree, it always - should be readed fully, but sequentially, so index search performance is + This index is useful if a table has many attributes and queries include + arbitrary combinations of them. A traditional btree index is faster + than a bloom index, but it can require many indexes to support all possible + queries where one needs only a single bloom index. A Bloom index supports only + equality comparison. Since it's a signature file, and not a tree, it always + must be read fully, but sequentially, so that index search performance is constant and doesn't depend on a query. @@ -41,7 +41,7 @@ Parameters - bloom indexes accept following parameters in WITH + bloom indexes accept the following parameters in the WITH clause. @@ -71,7 +71,7 @@ Examples - Example of index definition is given below. + An example of an index definition is given below. @@ -80,12 +80,12 @@ - Here, we create bloom index with signature length 80 bits and attributes - i1, i2 mapped to 2 bits, attribute i3 - to 4 bits. + Here, we created a bloom index with a signature length of 80 bits, + and attributes i1 and i2 mapped to 2 bits, and attribute i3 to 4 bits. - Example of index definition and usage is given below. + Here is a fuller example of index definition and usage: @@ -142,7 +142,7 @@ - Btree index will be not used for this query. + A btree index will be not used for this query. @@ -162,9 +162,9 @@ Opclass interface - Bloom opclass interface is simple. It requires 1 supporting function: - hash function for indexing datatype. And it provides 1 search operator: - equality operator. The example below shows opclass definition + The Bloom opclass interface is simple. It requires 1 supporting function: + a hash function for the indexing datatype. It provides 1 search operator: + the equality operator. The example below shows opclass definition for text datatype. @@ -183,16 +183,16 @@ - For now, only opclasses for int4, text comes - with contrib. However, users may define more of them. + For now, only opclasses for int4, text come + with the module. However, users may define more of them. - Only = operator is supported for search now. But it's - possible to add support of arrays with contains and intersection - operations in future. + Only the = operator is supported for search at the moment. But it's + possible to add support for arrays with contains and intersection + operations in the future. -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Introduce parse_ident()
On 2016-03-18 16:25, Teodor Sigaev wrote:
Introduce parse_ident()
SQL-layer function to split qualified identifier into array parts.
[...]
Details
---
http://git.postgresql.org/pg/commitdiff/3187d6de0e5a9e805b27c48437897e8c39071d45
Modified Files
--
doc/src/sgml/func.sgml | 26
Fixed a typo and added 'the' a few times.
Erik Rijkers
--- doc/src/sgml/func.sgml.orig 2016-03-18 16:31:02.896878016 +0100
+++ doc/src/sgml/func.sgml 2016-03-18 16:33:19.727724710 +0100
@@ -1832,12 +1832,12 @@
false, extra characters after the identifier are ignored. This is useful
for parsing identifiers for objects like functions and arrays that may
have trailing characters. By default, extra characters after the last
- identifier are considered an error, but if second parameter is false,
- then chararacters after last identifier are ignored. Note that this
+ identifier are considered an error, but if the second parameter is false,
+ then the characters after the last identifier are ignored. Note that this
function does not truncate quoted identifiers. If you care about that
- you should cast the result of this function to name[]. A non-printable
- chararacters (like 0 to 31) are displayed as hexadecimal codes always,
- what can be different from PostgreSQL internal SQL identifiers
+ you should cast the result of this function to name[]. Non-printable
+ characters (like 0 to 31) are always displayed as hexadecimal codes,
+ which can be different from PostgreSQL internal SQL identifiers
processing, when the original escaped value is displayed.
parse_ident('"SomeSchema".someTable')
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Use gender-neutral language in documentation
On 2015-09-22 04:59, Peter Eisentraut wrote: Use gender-neutral language in documentation Based on patch by Thomas Munro <thomas.mu...@enterprisedb.com>, although I rephrased most of the initial work. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/741ccd5015f82e31f80cdc5d2ae81263ea92d794 I think this compulsive 'he'-avoiding is making the text worse. - environment variable); any user can make such a change for his session. + environment variable); any user can make such a change for their session. Yuck. even worse: - might not be the same as the database user he needs to connect as. + might not be the same as the database user that is to be connect as. It is not an improvement. I would like to see this change rolled back. thanks, Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: contrib/tsm*
It seems two .sgml files are missing (and this prevents the docs from building): tsm-system-rows.sgml, and tsm-system-time.sgml openjade:contrib.sgml:145:1:E: cannot find tsm-system-rows.sgml; tried tsm-system-rows.sgml, ./tsm-system-rows.sgml, ./tsm-system-rows.sgml, /usr/share/sgml/tsm-system-rows.sgml, /usr/share/xml/tsm-system-rows.sgml openjade:contrib.sgml:146:1:E: cannot find tsm-system-time.sgml; tried tsm-system-time.sgml, ./tsm-system-time.sgml, ./tsm-system-time.sgml, /usr/share/sgml/tsm-system-time.sgml, /usr/share/xml/tsm-system-time.sgml thanks, Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Fix typos in comments.
On Thu, May 22, 2014 06:00, Fujii Masao wrote:
Fix typos in comments.
while you're at it: here is another one ('the the').
thanks
--- src/include/utils/jsonb.h.orig 2014-05-22 06:50:30.227013363 +0200
+++ src/include/utils/jsonb.h 2014-05-22 06:50:54.721266962 +0200
@@ -93,7 +93,7 @@
*
* The root node is an exception; it has no parent array or object that could
* hold its JEntry. Hence, no JEntry header is stored for the root node. It
- * is implicitly known that the the root node must be an array or an object,
+ * is implicitly known that the root node must be an array or an object,
* so we can get away without the type indicator as long as we can distinguish
* the two. For that purpose, both an array and an object begins with a uint32
* header field, which contains an JB_FOBJECT or JB_FARRAY flag. When a naked
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Tweak wording in sequence-function docs to avoid PDF build failu
On Thu, June 27, 2013 06:28, Tom Lane wrote: Tweak wording in sequence-function docs to avoid PDF build failures. This does indeed fix the .PDF building I reported a few weeks ago. Thank you very much! Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Create libpgcommon, and move pg_malloc et al to it
On Tue, February 12, 2013 15:55, Alvaro Herrera wrote: Create libpgcommon, and move pg_malloc et al to it If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as such. (it's not a big deal but I often have large databases in a dev/test-setup that take a while to re-create...) Thanks, Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Create libpgcommon, and move pg_malloc et al to it
On Tue, February 12, 2013 17:01, Alvaro Herrera wrote: Erik Rijkers wrote: On Tue, February 12, 2013 15:55, Alvaro Herrera wrote: Create libpgcommon, and move pg_malloc et al to it If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as such. Hmm? I don't think this patch requires an initdb at all. It doesn't touch the database contents at all, does it? Patches that force an initdb are flagged as such by bumping CATALOG_VERSION_NO. I got this: The database cluster was initialized with PG_CONTROL_VERSION 934, but the server was compiled with PG_CONTROL_VERSION 935 HINT: It looks like you need to initdb But I immediately admit that I could well be mistaken; it may have been an older commit that triggered this complaint of 'needing initdb' on this particular machine. My apologies. Thanks, Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Create libpgcommon, and move pg_malloc et al to it
On Tue, February 12, 2013 17:19, Alvaro Herrera wrote: Erik Rijkers wrote: On Tue, February 12, 2013 17:01, Alvaro Herrera wrote: Erik Rijkers wrote: On Tue, February 12, 2013 15:55, Alvaro Herrera wrote: Create libpgcommon, and move pg_malloc et al to it If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as such. Hmm? I don't think this patch requires an initdb at all. It doesn't touch the database contents at all, does it? Patches that force an initdb are flagged as such by bumping CATALOG_VERSION_NO. I got this: The database cluster was initialized with PG_CONTROL_VERSION 934, but the server was compiled with PG_CONTROL_VERSION 935 HINT: It looks like you need to initdb But I immediately admit that I could well be mistaken; it may have been an older commit that triggered this complaint of 'needing initdb' on this particular machine. My apologies. Ah, yes, that's 62401db45c. I'm not sure are you suggesting, though. Are you saying that the commit message should explicitely state this patch requires initdb or some such? I was under the impression that this was habitually done in commit messages, but looking back through the commitlog messages it's not all that clear although sometimes catversion bumps are explicitly mentioned. Let's just say that an explicit mention/warning is useful for me, so probably for some others too. At the same time I'll start monitoring PG_CONTROL_VERSION and CATALOG_VERSION a bit more closely. That's easy enough too of course... Thanks, Erik Rijkers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: psql: Improve expanded print output in tuples-only mode
On Sat, February 9, 2013 06:24, Peter Eisentraut wrote: psql: Improve expanded print output in tuples-only mode When there are zero result rows, in expanded mode, (No rows) is printed. So far, there was no way to turn this off. Now, when tuples-only mode is turned on, nothing is printed in this case. Good, that's definitely an improvement. But can we not remove that empty line alltogether in tuples-only mode? At the moment: $ echo '\dt+ diffs*' | psql --tuples-only public | diffs_2013_01 | table | aardvark | 8456 kB | public | diffs_2013_02 | table | aardvark | 7832 kB | $ The trailing empty line here makes almost as little sense as in the now amended case where there are zero rows ... (Of course, I realise that it's much more likely to break existing scripts, but should we then keep such illogical things forever at all cost?) Thanks, Erik Rijkers Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8ade58a4ea318d0ab8548ab94e49a3b80fdbeb0d Modified Files -- src/bin/psql/print.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
