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
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
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
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
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
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 a
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 pg_import_system_collations().
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 that. Much like the "IC
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 I
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 ha
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
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
--
Sen
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 work.
I think end users would be s
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 which makes the
system th
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 super-user-
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
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.
A
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
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
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
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
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
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
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.
>
&
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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_
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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 loc
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 grovell
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 fro
attached a patch where I
add completion for \h ALTER and \h DROP.
Andreas
commit 045c92b10eb8777d29fc920c55561d645c0b8f30
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
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
recal
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
On 01/04/2017 03:48 PM, Magnus Hagander wrote:
On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane
That means storing the pass phrase in the memory of the postmaster,
which does not sound like a terribly good idea to me, but I have never
used keys with pass phrases for daemons so it might be a common so
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 follow
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 i
On 12/04/2016 03:20 PM, Michael Paquier wrote:
On Sun, Dec 4, 2016 at 11:11 PM, Andreas Karlsson 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 context is actually loaded or
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 t
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).
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 be_tls_init
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
5ff4a67f63fd6d3eb
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
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 nothi
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
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 'connected
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 the
On 11/24/2016 08:46 AM, Michael Paquier wrote:
On Sat, Nov 12, 2016 at 3:42 AM, Andreas Karlsson 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 rather than restart
Did you
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
1 - 100 of 356 matches
Mail list logo
