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

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

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

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

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] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 09/21/2017 10:55 PM, Peter Geoghegan wrote: I agree, but the bigger issue is that we're *half way* between supporting only one format, and supporting two formats. AFAICT, there is no reason that we can't simply support one format on all ICU versions, and keep what ends up within pg_collation

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 09/21/2017 01:40 AM, Peter Geoghegan wrote: On Wed, Sep 20, 2017 at 4:08 PM, Peter Geoghegan wrote: pg_import_system_collations() takes care to use the non-BCP-47 style for such versions, so I think this is working correctly. But CREATE COLLATION doesn't use

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 09/19/2017 11:32 PM, Peter Geoghegan wrote: On Tue, Sep 19, 2017 at 2:22 PM, Tom Lane wrote: Well, if PG10 shipped with that restriction in place then it wouldn't be an issue ;-) I was proposing that this be treated as an open item for v10; sorry if I was unclear on

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 09/19/2017 12:46 AM, Peter Geoghegan wrote:> At one point a couple of months back, it was understood that get_icu_language_tag() might not always work with (assumed) valid locale names -- that is at least the impression that the commit message of eccead9 left me with. But, that was only with

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

I have not looked at the issue with the btree_gin tests yet, but here is the first part of my review. = Review This is my first quick review where I just read the documentation and quickly tested the feature. I will review it more in-depth later. This is a very useful feature, one which I

Re: [HACKERS] GnuTLS support

On 09/15/2017 06:55 PM, Jeff Janes wrote: I can't build against gnutls-2.12.23-21.el6.x86_64 from CentOS 6.9 Thanks for testing my patch. I have fixed both these issues plus some of the other feedback. A new version of my patch is attached which should, at least on theory, support all GnuTLS

Re: [HACKERS] postgres_fdw super user checks

On 09/14/2017 08:33 PM, Jeff Janes wrote:> Attached is a new patch which fixes the style issue you mentioned. Thanks, the patch looks good no,w and as far as I can tell there was no need to update the comments or the documentation so I am setting this as ready for committer. Andreas --

Re: [HACKERS] generated columns

On 09/13/2017 04:04 AM, Simon Riggs wrote: On 31 August 2017 at 05:16, Peter Eisentraut wrote: - index support (and related constraint support) Presumably you can't index a VIRTUAL column. Or at least I don't think its worth spending time trying to make it

Re: [HACKERS] Patches that don't apply or don't compile: 2017-09-12

On 09/12/2017 04:14 PM, Aleksander Alekseev wrote: Title: Foreign Key Arrays Author: Mark Rofail URL:https://commitfest.postgresql.org/14/1252/ I am currently reviewing this one and it applies, compiles, and passes the test suite. It could be the compilation warnings

Re: [HACKERS] postgres_fdw super user checks

On 07/27/2017 09:45 PM, Jeff Janes wrote:> Here is an updated patch.  This version allows you use the password-less connection if you either are the super-user directly (which is the existing committed behavior), or if you are using the super-user's mapping because you are querying a

Re: [HACKERS] GnuTLS support

On 09/07/2017 11:34 PM, Tomas Vondra wrote: I am worried about having 3x version of TLS controls in postgresql.conf, and only one set being active. Perhaps we need to break out the TLS config to separate files or something. Anyway, this needs more thought. Well, people won't be able to set the

[HACKERS] GnuTLS support

Hi, I have seen discussions from time to time about OpenSSL and its licensing issues so I decided to see how much work it would be to add support for another TLS library, and I went with GnuTLS since it is the library I know best after OpenSSL and it is also a reasonably popular library.

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

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

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

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

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

Re: [HACKERS] CTE inlining

On 05/02/2017 04:38 AM, Craig Ringer wrote: On 1 May 2017 at 22:26, Andreas Karlsson <andr...@proxel.se> 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 ma

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 <andr...@proxel.se > 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 > r

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

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] 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

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.

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

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

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

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 ---

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 <andr...@proxel.se> 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 reind

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

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:

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

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] 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

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.

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] 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

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

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

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] 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

Re: [HACKERS] \h tab-completion

7d691929f5814da87bb8a532e7dcfa2bd1dc9f15 Author: Andreas Karlsson <andr...@proxel.se> 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/ps

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

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

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] 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 <andr...@proxel.se> wrote: +/* + * Copy contraint flags for old index. This is safe because the old index + * guaranteed uniquness. + */ +newIndexForm->indisprimary = old

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.

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

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 <andr...@proxel.se> 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

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] rename pg_log directory?

on for why global and base do not have the "pg_" prefix? Andreas commit 0b71fcdb328f05349775675e0491ba1b82127d4e Author: Andreas Karlsson <andr...@proxel.se> Date: Mon Mar 6 23:52:49 2017 +0100 Rename default log directory from pg_log to log diff --git a/doc/src/sgml/

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] 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

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

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

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

[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,

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

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 <andr...@proxel.se> 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 (V

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 02/13/2017 06:31 AM, Michael Paquier wrote: - What should we do with REINDEX DATABASE CONCURRENTLY and the system catalog? I so not think we can reindex the system catalog concurrently safely, so what should REINDEX DATABASE do with the catalog indexes? Skip them, reindex them while taking

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 02/02/2015 03:10 PM, Andres Freund wrote: I think if we should instead just use the new index, repoint the dependencies onto the new oid, and then afterwards, when dropping, rename the new index one onto the old one. That means the oid of the index will change and some less than pretty

Re: [HACKERS] 'text' instead of 'unknown' in Postgres 10

On 02/07/2017 03:14 PM, Daniele Varrazzo wrote: In psycopg '{}'::unknown is treated specially as an empty array and converted into an empty list, which allows empty lists to be passed to the server as arrays and returned back to python. Without the special case, empty lists behave differently

Re: [HACKERS] \h tab-completion

attached a patch where I add completion for \h ALTER and \h DROP. Andreas commit 045c92b10eb8777d29fc920c55561d645c0b8f30 Author: Andreas Karlsson <andr...@proxel.se> Date: Fri Feb 3 13:05:48 2017 +0100 Add compleition for \help DROP|ALTER diff --git a/src/bin/psql/tab-complete.c

Re: [HACKERS] Checksums by default?

On 01/21/2017 04:48 PM, Stephen Frost wrote: * Fujii Masao (masao.fu...@gmail.com) wrote: If the performance overhead by the checksums is really negligible, we may be able to get rid of wal_log_hints parameter, as well. Prior benchmarks showed it to be on the order of a few percent, as I

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

On 01/04/2017 04:14 PM, Stephen Frost wrote: * Andreas Karlsson (andr...@proxel.se) wrote: A possible solution might be to only add the error throwing hook when loading certificates during SIGHUP (and at Windows) and to work as before on startup. Would that be an acceptable solution? I could

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

On 01/04/2017 03:48 PM, Magnus Hagander wrote: On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane

Re: [HACKERS] pg_sequence catalog

On 01/03/2017 03:30 PM, Peter Eisentraut wrote: On 1/3/17 7:23 AM, Kuntal Ghosh wrote: The regression tests for hot standby check fails since it uses the following statement: -select min_value as sequence_min_value from hsseq; which is no longer supported I guess. It should be modified as

Re: [HACKERS] Why does plpython delay composite type resolution?

On 12/21/2016 04:14 AM, Jim Nasby wrote: Why do functions that accept composite types delay type resolution until execution? I have a naive patch that speeds up plpy.execute() by 8% by caching interred python strings for the dictionary key names (which are repeated over and over). The next step

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

On 12/04/2016 03:20 PM, Michael Paquier wrote: On Sun, Dec 4, 2016 at 11:11 PM, Andreas Karlsson <andr...@proxel.se> wrote: On 12/04/2016 02:12 PM, Michael Paquier wrote: One last thing that I think is missing in this patch is for users the possibility to check via SQL if the SSL c

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

On 12/04/2016 02:12 PM, Michael Paquier wrote: One last thing that I think is missing in this patch is for users the possibility to check via SQL if the SSL context is actually loaded or not. As the context is reloaded after all the new values are available, with the current patch users may see

Re: [HACKERS] pg_sequence catalog

I think this patch looks good now so I am setting it to ready for committer. I like the idea of the patch and I think that while this change will break some tools which look at the sequence relations I think the advantages are worth it (for example making more sequence DDL respecting MVCC).

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

On 11/30/2016 06:52 AM, Michael Paquier wrote: On Mon, Nov 28, 2016 at 2:01 PM, Michael Paquier Looking at the latest patch at code-level, there is some refactoring to introduce initialize_context(). But it is actually not necessary (perhaps this is the remnant of a past version?) as

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

On 12/01/2016 02:48 AM, Andres Freund wrote: It appears openssl has removed the public definition of EVP_CIPHER_CTX leading to pgcrypto failing with: Yes, I believe this is one of the changes in OpenSSL 1.1. I guess you might be the first one to try to compile with 1.1 since

Re: [HACKERS] Broken SSL tests in master

On 11/25/2016 07:19 AM, Tsunakawa, Takayuki wrote: Specifying multiple hosts is a new feature to be introduced in v10, so that's here: https://www.postgresql.org/docs/devel/static/libpq-connect.html Thanks, I had missed that patch. If we add support for multiple hosts I think we should also

Re: [HACKERS] Broken SSL tests in master

On 11/25/2016 06:11 AM, Tsunakawa, Takayuki wrote: However, I wonder whether the hostaddr parameter should also accept multiple IP addresses. Yeah, I too thought about if we should fix that. I feel like it would make sense to add support for multiple hostaddrs. For consitency's sake if

Re: [HACKERS] Broken SSL tests in master

On 11/24/2016 10:38 PM, Andreas Karlsson wrote: To me it feels like the proper fix would be to make PQHost() return the value of the host parameter rather than the hostaddr (maybe add a new field in the pg_conn_host struct). But would be a behaviour change which might break someones application

[HACKERS] Broken SSL tests in master

Hi, The SSL test suite (src/test/ssl) is broken in the master since commit 9a1d0af4ad2cbd419115b453d811c141b80d872b, which is Robert's refactoring of getting the server hostname for GSS, SSPI, and SSL in libpq. The error we get in the test suite: # Running: psql -X -A -t -c SELECT

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

On 11/24/2016 02:49 PM, Andreas Karlsson wrote: Thanks for finding this. I will look at this more once I get home, but the tests do not fail on my computer. I wonder what I do differently. What versions of Perl and OpenSSL do you run and how did you run the tests when the failed? I ran

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

On 11/24/2016 08:46 AM, Michael Paquier wrote: On Sat, Nov 12, 2016 at 3:42 AM, Andreas Karlsson <andr...@proxel.se> wrote: On 11/11/2016 07:40 PM, Andreas Karlsson wrote: Here is a new version of the patch with the only differences; 1) The SSL tests have been changed to use reload

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

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

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

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

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] [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 ---

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 includes

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 <andr...@proxel.se> 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

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/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: ---

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

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

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,

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 +++

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

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

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

  1   2   3   4   >