Re: [HACKERS] Submit Pull Request

On 03/03/2016 12:11 PM, Maton, Brett wrote: How do I push a branch to git.postgresql.org/git/pgrpms.git ? I would email pgsql-pkg-...@postgresql.org, as mentioned at http://yum.postgresql.org/contact.php, with questions about how to contribute to

Re: [HACKERS] syslog configurable line splitting behavior

On 02/27/2016 04:49 AM, Peter Eisentraut wrote: So I propose the two attached patches that introduce new configuration Boolean parameters syslog_sequence_numbers and syslog_split_lines that can toggle these behaviors. As someone who uses syslog for my servers I find both of these GUCs useful,

Re: [HACKERS] syslog configurable line splitting behavior

On 03/09/2016 03:20 AM, Peter Eisentraut wrote: On 3/8/16 9:12 PM, Andreas Karlsson wrote: As someone who uses syslog for my servers I find both of these GUCs useful, especially when used in combination, and I do not think a compile time option like suggest by Alexander would be suitable

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On 03/08/2016 01:24 AM, Regina Obe wrote: On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe > wrote: I think the answer to this question is NO, but thought I'd ask. A lot of folks in PostGIS land are suffering from restore issues, materialized view issues etc. because we have functions such as ST_Inte

Re: [HACKERS] NOT LIKE index support

On 03/15/2016 11:01 PM, Arjen Nienhuis wrote: I noticed index support for NOT LIKE is missing. Is there a special reason for that, or would a patch be accepted? A use case would be: ... WHERE url NOT LIKE 'http%' Or ... WHERE path NOT LIKE '/%' My guess is the lack of many compelling use ca

Re: [HACKERS] syslog configurable line splitting behavior

On 03/16/2016 03:50 AM, Peter Eisentraut wrote: On 3/8/16 9:12 PM, Andreas Karlsson wrote: I have one nitpick: why is one of the variables "true" while the other is "on" in the example? I think both should be "on". #syslog_sequence_numbers = true #syslog_spli

Re: [HACKERS] POC, WIP: OR-clause support for indexes

I gave this patch a quick spin and noticed a strange query plan. CREATE TABLE test (a int, b int, c int); CREATE INDEX ON test USING gin (a, b, c); INSERT INTO test SELECT i % 7, i % 9, i % 11 FROM generate_series(1, 100) i; EXPLAIN ANALYZE SELECT * FROM test WHERE (a = 3 OR b = 5) AND c =

Re: [HACKERS] 2016-03 Commitfest

Hi, The COPY RAW patch seems to have two entries in the commitfest. https://commitfest.postgresql.org/9/223/ and https://commitfest.postgresql.org/9/547/ Are those about the same patch? Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On 03/23/2016 01:55 PM, Eduardo Morras wrote: Benefits: Dynamic multihoming, modifiable at run time, don't need aggregate links at OS level or shutdown servers/clients for a hardware or topology network change. Message oriented connection. Message reliability. Inmune to SYN floods that affect t

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On 03/23/2016 02:13 PM, Alvaro Herrera wrote: Andreas Karlsson escribió: On 03/23/2016 01:55 PM, Eduardo Morras wrote: Benefits: Dynamic multihoming, modifiable at run time, don't need aggregate links at OS level or shutdown servers/clients for a hardware or topology network change. Me

Re: [HACKERS] NOT EXIST for PREPARE

On 03/23/2016 09:10 PM, Stephen Frost wrote: * Merlin Moncure (mmonc...@gmail.com) wrote: No one is arguing that that you should send it any every time (at least -- I hope not). I'm not sure I follow how you can avoid that though? pgbouncer in transaction pooling mode may let a particular con

Re: [HACKERS] NOT EXIST for PREPARE

On 03/24/2016 11:21 PM, Merlin Moncure wrote: Personally I think the right solution would be to add support for prepared statements in pgbouncer, and have pgbouncer run PREPARE as necessary, either after opening a new connection to the database or at the first use of a given prepared statement in

Re: [HACKERS] COPY (... tab completion

the parentheses is documented to be: SELECT, VALUES, INSERT, UPDATE or DELETE; and actually TABLE should also work. Your list doesn't include all of those. So please adjust that. Fixed. And TABLE works too. Andreas commit 3b7a808e710e613f81abd0207847a3378ec3192c Author: Andreas K

Re: [HACKERS] COPY (... tab completion

On 01/19/2016 01:57 AM, Andreas Karlsson wrote: Thanks for the review. A new version is attached. Whops, attached the wrong file. Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index ad8a580..bc80ed0 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/11/2016 02:39 AM, Peter Eisentraut wrote: The second part is not necessary, because there is already code that completes FDW names after "FOREIGN DATA WRAPPER". So this already works. Good spot, thanks. I have no idea why I did not think it worked. Maybe it just did not work in 9.2 and

Re: [HACKERS] COPY (... tab completion

On 01/19/2016 07:55 AM, Michael Paquier wrote: +/* If we have COPY BINARY, compelete with list of tables */ s/compelete/complete Fixed. +else if (TailMatches2("COPY|\\copy", "(")) +COMPLETE_WITH_LIST7("SELECT", "TABLE", "VALUES", "INSERT", "UPDATE", "DELETE", "WITH"); This one

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/23/2016 01:03 PM, Peter Eisentraut wrote: committed Thanks! Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Generalizing SortSupport for text to work with char(n), bytea, and alternative opclasses

Hi, I have reviewed this now and I think this is a useful addition even though these indexes are less common. Consistent behavior is worth a lot in my mind and this patch is reasonably small. The patch no longer applies due to 1) oid collisions and 2) a trivial conflict. When I fixed those t

Re: [HACKERS] UNIQUE capability to hash indexes

On 02/04/2016 11:34 PM, Tom Lane wrote: Alvaro Herrera writes: This is really strange though. Surely adding WAL-logging is not an enormous task anymore ... I mean, we're undertaking far larger efforts now, the WAL logging code is simpler than before, and we even have a tool (ok, gotta streamli

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 08/26/2016 07:04 PM, Heikki Linnakangas wrote: On 08/26/2016 07:44 PM, Tom Lane wrote: Peter Eisentraut writes: On 8/26/16 5:31 AM, Heikki Linnakangas wrote: I think now would be a good time to drop support for OpenSSL versions older than 0.9.8. OpenSSL don't even support 0.9.8 anymore, al

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 08/29/2016 07:22 PM, Heikki Linnakangas wrote: Pushed with some small doc fixes, thanks Andreas! I'll continue reviewing the rest of the patches. Thanks! Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgre

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 08/26/2016 11:31 AM, Heikki Linnakangas wrote: On 07/05/2016 04:46 PM, Andreas Karlsson wrote: @@ -280,8 +287,9 @@ px_find_digest(const char *name, PX_MD **res) digest = px_alloc(sizeof(*digest)); digest->algo = md; -EVP_MD_CTX_init(&digest->ctx); -if (EVP_Dig

Re: [HACKERS] Improve BEGIN tab completion

On 09/01/2016 11:28 PM, Kevin Grittner wrote: On Wed, May 18, 2016 at 8:59 AM, Andreas Karlsson wrote: I noticed that the tab completion was not aware of that TRANSACTION/WORK is optional in BEGIN, and that we do not complete [NOT] DEFERRABLE. While fixing it I also improved the completion

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 08/31/2016 11:34 PM, Peter Geoghegan wrote: On Sun, Nov 22, 2015 at 7:29 PM, Andreas Karlsson wrote: Sorry for dropping this patch, but now I have started looking at it again. Any chance of picking this up again soon, Andreas? I think it's an important project. I would like to revi

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

//www.postgresql.org/message-id/561274f1.1030...@iki.fi). I dropped the ball back then, but I think I'll go ahead and do that now, once we get these other OpenSSL changes in. Nice! Andreas >From 0afeb5e075028339f28c2c2d7b407c1bcc85c4be Mon Sep 17 00:00:00 2001 From: Andreas Karlsson Da

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/05/2016 02:23 AM, Tom Lane wrote: Judging by the number of people who have popped up recently with their own OpenSSL 1.1 patches, I think there is going to be a lot of demand for back-patching some sort of 1.1 support into our back branches. All this talk of refactoring does not sound very

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/12/2016 06:51 PM, Heikki Linnakangas wrote: Changes since last version: * Added more error checks to the my_BIO_s_socket() function. Check for NULL result from malloc(). Check the return code of BIO_meth_set_*() functions; looking at OpenSSL sources, they always succeed, but all the test/e

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/15/2016 02:03 AM, Andreas Karlsson wrote: On 09/12/2016 06:51 PM, Heikki Linnakangas wrote: Changes since last version: * Added more error checks to the my_BIO_s_socket() function. Check for NULL result from malloc(). Check the return code of BIO_meth_set_*() functions; looking at

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/15/2016 05:38 PM, Alvaro Herrera wrote: I suppose some interested party could grab the patch that Heikki committed to the new branches and produce a back-patch that can be applied to the older branches. Here is the result of backporting the sum of the two patches on top of REL9_4_STABLE.

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/16/2016 04:11 PM, Christoph Berg wrote: Thanks for the patch! I just tried to apply it to 9.2. There was a conflict in configure.in which was trivial to resolve. Another conflict in contrib/pgcrypto/pgcrypto.c was not applicable because the code doesn't seem to exist (didn't try very hard

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Sorry for the very late review. I like this feature and have needed it myself in the past, and the current syntax seems pretty good. One could argue for if the syntax could be generalized to support other things like json and hstore, but I do not think it would be fair to block this patch due

Re: [HACKERS] git down

On 10/27/2017 10:51 PM, Erik Rijkers wrote: git.postgresql.org is down/unreachable ( git://git.postgresql.org/git/postgresql.git ) Yes, I noticed this too, but https://git.postgresql.org/git/postgresql.git still works fine. I guess it makes sense to remove unencrypted access, but in that ca

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Here is a rebased version of the patch. Andreas diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index a0ca2851e5..f8c59ea127 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -926,6 +926,7 @@ ERROR: could not serialize access due to read/write dependencies among tr

Re: [HACKERS] GnuTLS support

On 09/18/2017 07:04 PM, Jeff Janes wrote:> You fixed the first issue, but I still get the second one: be-secure-gnutls.c: In function 'get_peer_certificate': be-secure-gnutls.c:667: error: 'GNUTLS_X509_CRT_LIST_SORT' undeclared (first use in this function) be-secure-gnutls.c:667: error: (Each u

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On 11/10/2017 01:47 AM, Mark Rofail wrote: I am sorry for the late reply There is no reason for you to be. It did not take you 6 weeks to do a review. :) Thanks for this new version. == Functional review >1) MATCH FULL does not seem to care about NULLS in arrays. In the example be

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

I have attached a version of the patch rebased on top of the OpenSSL 1.1 changes. Andreas diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c index 668f217..a1b582f 100644 --- a/src/backend/libpq/be-secure-openssl.c +++ b/src/backend/libpq/be-secure-openss

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

Thanks for the review! I have fixed all your feedback in the attached patch. On 11/03/2016 04:24 PM, Michael Banck wrote: It does not update the documentation, I think at least section 18.9 "Secure TCP/IP Connections with SSL" needs updating as it says: "The files server.key, server.crt, root.cr

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 11/08/2016 01:22 PM, Michael Banck wrote: Thanks! I couldn't find furhter faults in my testing. I guess the question what to do about this on Windows is possibly still open, but as I am not familiar with the Windows port at all I've marked it Ready for Committer for now. Thanks again for the

Re: [HACKERS] pg_sequence catalog

Review of the pg_sequences view. This seems like a useful addition to me, making life easier for administrators and monitoring tools. While there is already a view in information_schema it is missing cache_size and last_value. = Functional review - The patch applies and passes the test suite

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 11/09/2016 06:54 AM, Michael Paquier wrote: It seems to me that this patch is missing something... To begin with, src/test/ssl/ServerSetup.pm should be patched so as the new SSL configuration is reloaded after pg_ctl reload, and not after an instance restart. That's straight-forward: --- a/src

Re: [HACKERS] pg_sequence catalog

On 11/10/2016 05:29 AM, Peter Eisentraut wrote: On 11/8/16 6:43 PM, Andreas Karlsson wrote: - A worry is that it might get a bit confusing to have both the future catalog pg_sequence and the view pg_sequences. We already have this in other cases: pg_index/pg_indexes, pg_user_mapping

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 11/10/2016 07:16 AM, Michael Paquier wrote: On Wed, Nov 9, 2016 at 7:46 PM, Andreas Karlsson wrote: Those tests fail due to that listen_addresses cannot be changed on reload so none of the test cases can even connect to the database. When I hacked ServerSetup.pm to set the correct

Re: [HACKERS] pg_sequence catalog

On 11/10/2016 06:27 AM, Andreas Karlsson wrote: On 11/10/2016 05:29 AM, Peter Eisentraut wrote: On 11/8/16 6:43 PM, Andreas Karlsson wrote: - Shouldn't last_value be NULL directly after we have created the sequence but nobody has called nextval() yet? - I noticed that last_value include

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

Hi, Here is a new version of the patch with the only differences; 1) The SSL tests have been changed to use reload rather than restart 2) Rebased on master Please take a look. Andreas diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 787cfce..5e78d81 100644 --- a/doc/sr

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 11/11/2016 07:40 PM, Andreas Karlsson wrote: Hi, Here is a new version of the patch with the only differences; 1) The SSL tests have been changed to use reload rather than restart 2) Rebased on master And here with a fix to a comment. Andreas diff --git a/doc/src/sgml/runtime.sgml b

Re: [HACKERS] pg_sequence catalog

Review for pg_sequence catalog I like this change since it moves all the parts which should be transactional to the system catalogs while keeping the only non-transactional stuff in the sequence relations. There was some discussion upthread about more compact representations for the sequence

Re: [HACKERS] Contains and is contained by operators of inet datatypes

Review - Applies and passes the test suite. - I think this is a good change since it increases the consistency of the operators. I also like the choice of <<@ and @>> since they feel intuitive to me. - I tested it and both old and new operators use the brin and gist indexes. - The new spgis

Re: [HACKERS] Contains and is contained by operators of inet datatypes

On 11/13/2016 01:21 PM, Emre Hasegeli wrote: Thank you for the review. New version is attached. Nice, I am fine with this version of the patch. Setting it to ready for committer! Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscrip

Re: [HACKERS] Contains and is contained by operators of inet datatypes

On 11/17/2016 11:14 PM, Tom Lane wrote: The original post proposed that we'd eventually get some benefit by being able to repurpose << and >> to mean something else, but the time scale over which that could happen is so long as to make it unlikely to ever happen. I think we'd need to deprecate t

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 02/14/2017 04:56 AM, Michael Paquier wrote: On Tue, Feb 14, 2017 at 11:32 AM, Andreas Karlsson wrote: On 02/13/2017 06:31 AM, Michael Paquier wrote: Er, something like that as well, no? DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. REINDEX (VERBOSE) currently prints one

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 02/17/2017 01:53 PM, Andreas Karlsson wrote: I am actually thinking about going the opposite direction (by reducing the number of times we call WaitForLockers), because it is not just about consuming transaction IDs, we also do not want to wait too many times for transactions to commit. I am

[HACKERS] Question about memory contexts in ReindexMultipleTables()

Hi, When working on REINDEX CONCURRENTLY I noticed that the new memory context created in the ReindexMultipleTables() seems pointless. The purpose claimed in the code for introducing the ReindexMultipleTables context is to make sure the list we build with relation IDs survive the commit, sin

Re: [HACKERS] Disallowing multiple queries per PQexec()

On 02/28/2017 03:13 PM, Bruce Momjian wrote: I might have added that one; the text is: Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks and it is a "consider" item. Should it be moved to the Wire Protocol Changes / v4 Protocol

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Hi, Here is a third take on this feature, heavily based on Michael Paquier's 2.0 patch. This time the patch does not attempt to preserve the index oids, but instead creates new indexes and moves all dependencies from the old indexes to the new before dropping the old ones. The only downside I

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 03/02/2017 02:25 AM, Jim Nasby wrote: On 2/28/17 11:21 AM, Andreas Karlsson wrote: The only downside I can see to this approach is that we no logner will able to reindex catalog tables concurrently, but in return it should be easier to confirm that this approach can be made work. Another

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 03/05/2017 07:56 PM, Robert Haas wrote: On Sat, Mar 4, 2017 at 12:34 PM, Andres Freund wrote: I agree that'd it be nicer not to have this, but not having the feature at all is a lot worse than this wart. I, again, give that a firm "maybe". If the warts end up annoying 1% of the users who

Re: [HACKERS] rename pg_log directory?

On 03/01/2017 05:49 AM, Peter Eisentraut wrote: On 2/27/17 09:51, Tom Lane wrote: No objection to the basic point, but "log" seems perhaps a little too generic to me. Would something like "server_log" be better? Well, "log" is pretty well established. There is /var/log, and if you unpack a,

Re: [HACKERS] rename pg_log directory?

Btw, is there a reason for why global and base do not have the "pg_" prefix? Andreas commit 0b71fcdb328f05349775675e0491ba1b82127d4e Author: Andreas Karlsson Date: Mon Mar 6 23:52:49 2017 +0100 Rename default log directory from pg_log to log diff --git a/doc/src/sgml/config.sgml b/d

Re: [HACKERS] adding an immutable variant of to_date

On 03/03/2017 10:41 PM, Sven R. Kunze wrote: What do you think? I have some thoughts: 1) I do not think we currently allow setting the locale like this anywhere, so this will introduce a new concept to PostgreSQL. And you will probably need to add support for caching per locale. 2) As far

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 03/08/2017 03:48 AM, Robert Haas wrote: On Sun, Mar 5, 2017 at 7:13 PM, Andreas Karlsson wrote: And I would argue that his feature is useful for quite many, based on my experience running a semi-large database. Index bloat happens and without REINDEX CONCURRENTLY it can be really annoying

Re: [HACKERS] adding an immutable variant of to_date

On 03/07/2017 09:56 PM, Sven R. Kunze wrote: On 07.03.2017 03:21, Andreas Karlsson wrote: 1) I do not think we currently allow setting the locale like this anywhere, so this will introduce a new concept to PostgreSQL. And you will probably need to add support for caching per locale. Good to

Re: [HACKERS] rename pg_log directory?

On 03/09/2017 11:25 PM, Bruce Momjian wrote: "data" and "base" where chosen because it is a "data-base", but with the pg_ prefixes it would be a pg_data_pg_base. ;-) Haha, I had not spotted that one despite always naming my data directory "data" while developing. Fun little tidbit there. An

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 03/02/2017 03:10 AM, Michael Paquier wrote: On Wed, Mar 1, 2017 at 2:21 AM, Andreas Karlsson wrote: +/* + * Copy contraint flags for old index. This is safe because the old index + * guaranteed uniquness. + */ +newIndexForm->indisprimary = oldIndexForm->indisp

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 03/13/2017 03:11 AM, Andreas Karlsson wrote: I also fixed the the code to properly support triggers. And by "support triggers" I actually meant fixing the support for moving the foreign keys to the new index. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] \h tab-completion

On 03/13/2017 03:56 PM, David Steele wrote: Do you know when you will have a new patch available for review that incorporates Peter's request? I believe I will find the time to finish it some time in a couple of days. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] ICU integration

On 03/09/2017 10:13 PM, Peter Eisentraut wrote: - Naming of collations: Are we happy with the "de%icu" naming? I might have come up with that while reviewing the IPv6 zone index patch. ;-) An alternative might be "de$icu" for more Oracle vibe and avoiding the need for double quotes in some case

Re: [HACKERS] \h tab-completion

ommit 7d691929f5814da87bb8a532e7dcfa2bd1dc9f15 Author: Andreas Karlsson Date: Fri Feb 3 13:05:48 2017 +0100 Add compleition for \help DROP|ALTER diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index e8458e939e..3df7636c5b 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/tab-complete.c @@ -9

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, I got a test failure with this version of the patch in the postges_fdw. It looks to me like it was caused by a typo in the source code which is fixed in the attached patch. After applying this patch check-world passes. Andreas diff --git a/src/backend/executor/nodeTidscan.c b/src/backend

Re: [HACKERS] \h tab-completion

On 03/17/2017 12:01 AM, Peter Eisentraut wrote: Committed with some tweaking. Thanks! Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

On 03/18/2017 09:12 PM, Magnus Hagander wrote: createdb, dropdb - also not clear they're about postgres, more likely to be used by mistake but not that bad. That said, do they add any *value* beyond what you can do with psql -c "CREATE DATABASE"? I don't really see one, so I'd suggest dropping th

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

On 03/19/2017 07:35 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost writes: (Or in other words, we've been getting along fine with these script names for circa twenty years, so what's the rush to change them RIGHT NOW?) To be clear, I'm not in any particular rush

Re: [HACKERS] ICU integration

On 03/15/2017 05:33 PM, Peter Eisentraut wrote: Updated patch attached. Ok, I applied to patch again and ran the tests. I get a test failure on make check-world in the pg_dump tests but it can be fixed with the below. diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_

[HACKERS] Re: [REVIEW] psql tab completion for DROP TRIGGER/RULE and ALTER TABLE ... DISABLE/ENABLE

nternal is FALSE' to 'Query_for_trigger_of_table' to hide them. Good suggestion. I have attached a patch which filters out the internal triggers, both for ALTER TABLE and DROP TRIGGER. I am not entirely sure about the DROP TRIGGER case but I think I prefer no auto completion of RI tr

Re: [HACKERS] Re: [REVIEW] psql tab completion for DROP TRIGGER/RULE and ALTER TABLE ... DISABLE/ENABLE

On 06/18/2014 02:34 AM, Ian Barwick wrote: On 14/06/18 7:51, Andreas Karlsson wrote: On 06/17/2014 01:36 PM, Ian Barwick wrote: One issue - the table's internal triggers will also be listed. which can result in something like this: This is a bit of an extreme case, but I don't thin

Re: [HACKERS] New functions in sslinfo module

et_extension_names(). - All the "Returns X datum" comments look redundant to me, but this is a matter of preference. - The star when declaring result in ssl_get_extension_names() should be put on the other side of the white space. -- Andreas Karlsson -- Sent via pgsql-hackers mai

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

tch. The regression tests pass now on my Debian machine. One thing I noticed when trying to find the bug is that be-secure.c still includes some OpenSSL headers. Those should be removed since they have already been moved to be-secure-openssl.c. -- Andreas Karlsson diff --git a/src/backen

Re: [HACKERS] New functions in sslinfo module

any_to_server() is implemented using pg_do_encoding_conversion(). I don't write a code of those functions and I can't answer on your question. Hm, I thought I saw them changed from static to not in the diff after applying your patch. Maybe I just misread the patch. -- Andreas

Re: [HACKERS] ICU integration

I am fine with this version of the patch. The issues I have with it, which I mentioned earlier in this thread, seem to be issues with ICU rather than with this patch. For example there seems to be no way for ICU to validate the syntax of the BCP 47 locales (or ICU's old format). But I think we

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On 03/21/2017 08:02 AM, Haribabu Kommi wrote: Solution -1) Just ignore dumping these CREATE DATABASE commands and provide the user information in the documentation to create "postgres" and "template1" database in the target in case if they don't exist. If this kind of cases are very rare. Soluti

Re: [HACKERS] No more libedit?! - openssl plans to switch to APL2

On 08/01/2015 05:14 PM, Andres Freund wrote: According to https://www.openssl.org/blog/blog/2015/08/01/cla/ openssl is planning to relicense to the apache license 2.0. While APL2 is not compatible with GLP2 it *is* compatible with GPL3. Great! This means that the Debian packages will eventually

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Hi, Here is my review. I agree with the goal of the refactoring, as we want to make it easier to dump all the properties for the database object. But I think we need to solve the issues with the special casing of postgres and template1 which I personally would find very surprising if pg_dump

Re: [HACKERS] rename pg_log directory?

On 03/27/2017 04:38 PM, Peter Eisentraut wrote: Committed. Thanks! While digging around a bit, I found in release-old.sgml that before PostgreSQL 7.2, pg_clog was called pg_log. Go figure. Yeah, I noticed that too when writing the patch. :) Andreas -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On 03/29/2017 05:43 AM, Haribabu Kommi wrote: > Updated patch attached. I get a test failure in the pg_upgrade tests, but I do not have time right now to investigate. The failing test is "Restoring database schemas in the new cluster". I get the following in the log: command: "/home/andreas

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Thanks for the feedback. I will look at it when I get the time. On 03/31/2017 08:27 AM, Michael Paquier wrote: - Do a per-index rebuild and not a per-relation rebuild for concurrent indexing. Doing a per-relation reindex has the disadvantage that many objects need to be created at the same time,

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 04/03/2017 07:57 AM, Michael Paquier wrote: On Fri, Mar 31, 2017 at 5:12 PM, Andreas Karlsson wrote: On 03/31/2017 08:27 AM, Michael Paquier wrote: - Do a per-index rebuild and not a per-relation rebuild for concurrent indexing. Doing a per-relation reindex has the disadvantage that many

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 04/12/2017 04:12 PM, Tom Lane wrote: 1. The best thing would still be to make genbki.pl do the conversion, and write numeric OIDs into postgres.bki. The core stumbling block here seems to be that for most catalogs, Catalog.pm and genbki.pl never really break down a DATA line into fields --- a

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 04/12/2017 05:00 PM, Andreas Karlsson wrote: Looked at this an option 1 seems simple enough if I am not missing something. I might hack something up later tonight. Either way I think this improvement can be done separately from the proposed replacement of the catalog header files. Trying to

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 04/13/2017 06:13 PM, Tom Lane wrote: I've pushed this with some mostly-cosmetic adjustments: Thanks! I like your adjustments. There's certainly lots more that could be done in the genbki code, but I think all we can justify at this stage of the development cycle is to get the low-hanging f

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 04/14/2017 11:54 PM, Tom Lane wrote: I failed to resist the temptation to poke at this, and found that indeed nothing seems to break if we just use one transaction for the whole processing of postgres.bki. So I've pushed a patch that does that. We're definitely down to the point where worryi

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 04/16/2017 03:14 AM, Tom Lane wrote: 1. Back-patch that patch, probably also including the followup adjustments in 86029b31e and 36a3be654. 2. Add #if's to use 31cf1a1a4's coding with OpenSSL >= 1.1, while keeping the older code for use when built against older OpenSSLs. 3. Conditionall

Re: [HACKERS] Self-signed certificate instructions

On 04/15/2017 03:58 PM, Andrew Dunstan wrote: The instructions on how to create a self-signed certificate in s 18.9.3 of the docs seem unduly cumbersome. +1, I see no reason for us to spread unnecessarily complicated instructions. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

On 08/04/2017 08:48 PM, Shay Rojansky wrote: On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote: > I'm still not convinced of the risk/problem of simply setting the session > id context as I explained above (rather than disabling the optimization), > but of course either solution r

Re: [HACKERS] PG 10 release notes

is the author. + + + +Create a linkend="catalog-pg-sequence">pg_sequence system catalog to store sequence metadata (Andreas +Karlsson) + Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/m

Re: [HACKERS] CTE inlining

On 05/01/2017 04:17 PM, David Fetter wrote: Maybe we could allow a "decorator" that would tell the planner the CTE could be inlined? WITH INLINE mycte AS ( ...) +1 for a decorator, -1 for this one. I am not sure I like decorators since this means adding an ad hoc query hint directly int

Re: [HACKERS] CTE inlining

On 05/01/2017 04:33 PM, David G. Johnston wrote: > On Mon, May 1, 2017 at 7:26 AM, Andreas Karlsson I am not sure I like decorators since this means adding an ad hoc > query hint directly into the SQL syntax which is something which I > requires serious consideration. > &

Re: [HACKERS] CTE inlining

On 05/02/2017 04:38 AM, Craig Ringer wrote: On 1 May 2017 at 22:26, Andreas Karlsson wrote: I am not sure I like decorators since this means adding an ad hoc query hint directly into the SQL syntax which is something which I requires serious consideration. And mangling the semantics of

Re: [HACKERS] CTE inlining

On 05/03/2017 07:33 PM, Alvaro Herrera wrote: 1) we switch unmarked CTEs as inlineable by default in pg11. What seems likely to happen for a user that upgrades to pg11 is that 5 out of 10 CTE-using queries are going to become faster than with pg10, and they are going to be happy; 4 out of five a

Re: [HACKERS] CTE inlining

On 05/04/2017 06:22 PM, Andrew Dunstan wrote: I wrote this query: select (json_populate_record(null::mytype, myjson)).* from mytable; It turned out that this was an order of magnitude faster: with r as ( select json_populate_record(null::mytype, myjson) as x from

Re: [HACKERS] oidin / oidout and InvalidOid

On 06/12/2017 01:41 PM, Chapman Flack wrote: I was recently guilty of writing a less-than-clear SQL example because I plain forgot whether InvalidOid was 0 (correct) or -1 (my bad). Would there be any sense in letting oidin_subr accept the string InvalidOid for 0? I understand that changing oido

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

I have attached a new, rebased version of the batch with most of Banck's and some of your feedback incorporated. Thanks for the good feedback! On 03/31/2017 08:27 AM, Michael Paquier wrote> When running REINDEX SCHEMA CONCURRENTLY public on the regression database I am bumping into a bunch of

  1   2   3   4   >