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

//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] [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] 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] 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] 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 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] fixes for the Danish locale

On 07/22/2016 03:59 AM, Jeff Janes wrote: On Thu, Jul 21, 2016 at 2:11 PM, Tom Lane wrote: I see that the core tests fall over in Turkish still :-( Turkish has never passed (at least back to 9.0). It looks like it is in the stemming functions. I don't understand why, I would think everythin

Re: [HACKERS] bug in citext's upgrade script for parallel aggregates

On 07/09/2016 05:42 AM, David Rowley wrote: On 30 June 2016 at 03:49, Robert Haas wrote: On Sat, Jun 25, 2016 at 3:44 AM, Andreas Karlsson wrote: On 06/24/2016 01:31 PM, David Rowley wrote: Seems there's a small error in the upgrade script for citext for 1.1 to 1.2 which will caus

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 07/05/2016 11:13 AM, Victor Wagner wrote: On Fri, 1 Jul 2016 02:27:03 +0200 Andreas Karlsson wrote: 0003-Remove-OpenSSL-1.1-deprecation-warnings.patch Silence all warnings. This commit changes more things and is not necessary for getting PostgreSQL to build against 1.1. This patch breaks

Re: [HACKERS] to_date_valid()

On 07/04/2016 10:55 PM, Pavel Stehule wrote: 2016-07-04 22:15 GMT+02:00 Andreas Karlsson mailto:andr...@proxel.se>>: I do not see a clear conclusion in the linked threads. For example Bruce calls it a bug in one of the emails (https://www.postgresql.org/message-id/201107

Re: [HACKERS] to_date_valid()

On 07/03/2016 12:36 PM, Andreas 'ads' Scherbaum wrote: On 03.07.2016 07:05, Jaime Casanova wrote: Shouldn't we fix this instead? Sounds like a bug to me. We don't usually want to be bug compatible so it doesn't matter if we break something. There are previous discussions about such a change, a

Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

On 07/01/2016 07:31 PM, Andres Freund wrote: Yeah, but since when has the SQL standard adopted any existing implementation's spelling of a feature? It seems to be politically impossible. Especially if nobody really lobbies on part of postgresql. Has any of the major PostgreSQL companies looke

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 07/02/2016 02:45 AM, Andreas Karlsson wrote: On 07/02/2016 02:28 AM, Alvaro Herrera wrote: Generally, version number tests sprinkled all over the place are not terribly nice. I think it would be better to get configure to define a symbol like HAVE_BIO_METH_NEW. Not sure about the other

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 07/02/2016 02:28 AM, Alvaro Herrera wrote: static BIO_METHOD * my_BIO_s_socket(void) { - if (!my_bio_initialized) + if (!my_bio_methods) { - memcpy(&my_bio_methods, BIO_s_socket(), sizeof(BIO_METHOD)); - my_bio_methods.bread = my_sock_read; -

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

reas >From 59cb028a38c18cb2f8fff077d355a8a26ecce641 Mon Sep 17 00:00:00 2001 From: Andreas Karlsson Date: Tue, 28 Jun 2016 05:55:03 +0200 Subject: [PATCH 1/4] Fixes for compiling with OpenSSL 1.1 - Check for SSL_new now that SSL_library_init is a macro - Do not access struct members directly - RAND_SSLeay w

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

library and 2) no longer uses the locking callback. - Silences deprecation warning when generating DH parameters. Andreas >From 16bda89ea853d7ee160e049a300771b967f966ff Mon Sep 17 00:00:00 2001 From: Andreas Karlsson Date: Tue, 28 Jun 2016 05:55:03 +0200 Subject: [PATCH 1/3] Fixes for compil

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 06/27/2016 08:12 PM, Christoph Berg wrote: Re: Andreas Karlsson 2016-06-27 <8a0a5959-0b83-3dc8-d9e7-66ce8c1c5...@proxel.se> The errors you report make it sound like they broke API compatibility wholesale. Was that really their intent? If so, where are the changes documented? I do n

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 06/27/2016 05:24 PM, Tom Lane wrote: Christoph Berg writes: as reported by Debian's OpenSSL maintainers, PostgreSQL is failing to build against a snapshot of the upcoming 1.1.0 version. The errors you report make it sound like they broke API compatibility wholesale. Was that really their

Re: [HACKERS] bug in citext's upgrade script for parallel aggregates

On 06/24/2016 01:31 PM, David Rowley wrote: Seems there's a small error in the upgrade script for citext for 1.1 to 1.2 which will cause min(citext) not to be parallel enabled. max(citext)'s combinefunc is first set incorrectly, but then updated to the correct value. I assume it was meant to se

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/17/2016 09:11 PM, Robert Haas wrote: I was kind of hoping you'd have a new version of this posted already. beta2 is wrapping on Monday, and I'm inclined to shelve anything that isn't done by then for the next release. And I don't really plan to work much this weekend. Here they are. Shel

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/14/2016 09:55 PM, Robert Haas wrote: On Tue, Jun 14, 2016 at 1:51 PM, Robert Haas wrote: On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson wrote: I have rebased all my patches on the current master now (and skipped the extensions I previously listed). Thanks, this is really helpful

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/14/2016 07:51 PM, Robert Haas wrote: On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson wrote: I have rebased all my patches on the current master now (and skipped the extensions I previously listed). Thanks, this is really helpful. It was starting to get hard to keep track of what

[HACKERS] Use of CREATE OR REPLACE in bloom--1.0.sql

Hi, I do not think that extension SQL scripts should be using CREATE OR REPLACE FUNCTION like bloom--1.0.sql currently does. I suspect that this might just be a typo. I have attached the tiny patch which fixes this. Andreas diff --git a/contrib/bloom/bloom--1.0.sql b/contrib/bloom/bloom--1.0

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/07/2016 05:54 PM, Andreas Karlsson wrote: On 06/07/2016 05:44 PM, Robert Haas wrote: cube: I think we need a new extension version. hstore: Does not apply for me. intarray: Does not apply for me. Those three and ltree, pg_trgm, and seg depend on my patch with fixes for the GiST/GIN

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/10/2016 01:44 PM, Andreas Karlsson wrote: I have attached a patch which adds the shcema, plus an updated patch for tseach2. Forgot adding schema to the tables. Here are new versions. Andreas parallel-contrib-v4-tsearch2.patch.gz Description: application/gzip diff --git a/contrib

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/09/2016 10:48 PM, Tom Lane wrote: Robert Haas writes: On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote: Yes, let's fix it. This will also take care of the questions about whether the GIN/GIST opclass tweaks I made a few months ago require module version bumps. Tom, there's a patch f

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/07/2016 05:44 PM, Robert Haas wrote: adminpack: Doesn't seem useful. The case I imagined was if someone would use these functions on the result from a slow CTE and would want the CTE to be executed in parallel. I have no idea if that is a realistic case, but I rarely use adminpack in m

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/07/2016 05:44 PM, Robert Haas wrote: cube: I think we need a new extension version. hstore: Does not apply for me. intarray: Does not apply for me. Those three and ltree, pg_trgm, and seg depend on my patch with fixes for the GiST/GIN function signatures in https://www.postgresql.org/me

Re: [HACKERS] slower connect from hostnossl clients

On 06/07/2016 12:18 PM, Magnus Hagander wrote: > Intersting. Can you check with a network trace that it actually turns > off ssl, so nothing is broken there? > > One thing that could be taking the time is an extra roundtrip -- e.g. it > tries to connect with ssl fails and retries without. A networ

Re: [HACKERS] Parallel safety tagging of extension functions

Hi, Here is the patch split into many small patches as you suggested. The current patches are based on top of the patch which fixes the signatures for gin and gist functions. These patches only touch functions which never should be called directly, so they are fine to skip. I decided to atta

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/02/2016 01:41 AM, Michael Paquier wrote: > On Thu, Jun 2, 2016 at 7:36 AM, Andreas Karlsson wrote: >> Looked at this quickly and I do not think adding it would be what I consider >> a small patch since we would essentially need to copy the validation logic >> fro

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 03:32 AM, Tom Lane wrote: Andreas Karlsson writes: On 05/25/2016 02:41 AM, Robert Haas wrote: I'd rather extend see us ALTER AGGREGATE to do this. Wouldn't that prevent this from going into 9.6? I do not think changing ALTER AGGREGATE is 9.6 materials. Well, it&#

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/01/2016 05:15 PM, Tom Lane wrote: Andreas Karlsson writes: On 06/01/2016 04:44 PM, Tom Lane wrote: I don't understand why you think you need the CREATE OR REPLACE FUNCTION commands? We only need to change proargtypes, and the updates did that. The catcache can take care of i

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/01/2016 04:44 PM, Tom Lane wrote: Andreas Karlsson writes: It is the least ugly of all the ugly solutions I could think of. I have attached a patch which fixes the signatures using this method. I use CREATE OR REPLACE FUNCTION to update to catcache. What do you think? Is it too ugly? I

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/31/2016 06:47 PM, Tom Lane wrote: Given that, your original approach of manually updating proargtypes in the existing pg_proc row for the functions may be the best way. Anything else is going to be more complicated and ultimately will still require at least one direct catalog update. It

Re: [HACKERS] Binary I/O for isn extension

Hi, Thanks for the patch, you can add it to our commitfest app so it gets reviewed in the next commitfest. https://commitfest.postgresql.org/ A suggestion to make it easier for your patch to be accepted: When adding new functions to an extension you need to bump the version of the extension

Re: [HACKERS] IPv6 link-local addresses and init data type

On 05/31/2016 04:06 AM, Tom Lane wrote: Andreas Karlsson writes: On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The % delimiter character is not only used at the end of the IPV6 address, from the RFC document, it is possible as follows also. fe80::%2/64 we need to handle both the scenarios

Re: [HACKERS] IPv6 link-local addresses and init data type

On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The following is the content of IPV6 representation from RFC 4007 The following addresses fe80::1234 (on the 1st link of the node) ff02::5678 (on the 5th link of the node) ff08::9abc (on the 10th organizatio

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 03:37 AM, Tom Lane wrote: Andreas Karlsson writes: Ok, then I can avoid touching all functions which are only called by operator classes, tsearch, pls, fdws, etc. Which also means that there is no need to care about Tom's changes to the signatures of GIN and GiST su

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 03:09 AM, Robert Haas wrote: On Tue, May 24, 2016 at 8:41 PM, Robert Haas wrote: - Do you think we should add PARALLEL UNSAFE to the functions which we know are unsafe to make it obvious that it is intentional? That seems likely unnecessary churn from here. A general point her

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 02:41 AM, Robert Haas wrote: On Thu, May 19, 2016 at 5:50 PM, Andreas Karlsson wrote: - How should we modify the aggregate functions when upgrading extensions? ALTER AGGREGATE cannot change COMBINEFUNC or PARALLEL. My current patch updates the system catalogs directly, which

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 02:34 AM, Robert Haas wrote: On Fri, May 20, 2016 at 11:45 PM, Michael Paquier wrote: Sounds to me that this is part of the cleanup of a 9.6 feature and should be in that release. Yes, I agree. By the way, the patch completely ignores the fact that some of the modules already ha

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/21/2016 11:45 AM, Tom Lane wrote: Yes, let's fix it. This will also take care of the questions about whether the GIN/GIST opclass tweaks I made a few months ago require module version bumps. Do you have any idea what the best way to add these tweaks to the upgrade scripts would be? My

Re: [HACKERS] Parallel safety tagging of extension functions

Another question which I thought of is what we should do with functions like pg_file_write() in adminpack. While it is perfectly fine to modify files from the parallel workers, a user could get race conditions if he tries to modify the same file multiple times. Is this a kind of problem the PA

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/20/2016 11:45 PM, Michael Paquier wrote: Yes, I agree. By the way, the patch completely ignores the fact that some of the modules already had a version bump in the 9.6 development cycle, like pageinpect. You don't need to create a new version script in such cases. I assumed this was too l

[HACKERS] Parallel safety tagging of extension functions

Hi, I have gone through all our extensions and tried to tag all functions correctly according to their parallel safety. I also did the same for the aggregate functions in a second patch, and for min(citext)/max(citext) set a COMBINEFUNC. The changes for the functions is attached as one huge

[HACKERS] Improve BEGIN tab completion

Hi, 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 support for SET SESSION slightly. Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/t

Re: [HACKERS] Accidentally parallel unsafe functions

On 05/03/2016 08:45 PM, Robert Haas wrote: Committed all of this except for the bit about pg_start_backup, for which I committed a separate fix. Thanks, and really good that you spotted the pg_start_backup() issue. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Accidentally parallel unsafe functions

On 04/30/2016 01:19 AM, Tom Lane wrote: Alvaro Herrera writes: Surely CREATE OR REPLACE should keep whatever the flag was, rather than ovewrite it with a bogus value if not specified? In other words IMO the CREATE OR REPLACE code needs changing, not system_views.sql. Absolutely not! The def

[HACKERS] Accidentally parallel unsafe functions

ignore that one if you like. Affected functions: - json_populate_record() - json_populate_recordset() - jsonb_insert() - jsonb_set() - make_interval() - parse_ident() - Loads of conversion functions Andreas commit 9afcc5f1ed22be18d69dc0b70a0f057a023cc5ec Author: Andreas Karlsson Date: Fri

Re: [HACKERS] Can we improve this error message?

On 04/17/2016 09:28 PM, Bill Moran wrote: If you have a single line in the pg_hba.conf: hostssl all all 0.0.0.0/0 md5 Attempting to log in with an incorrect password results in an error message about there not being a pg_hba.conf entry for the user. Reading carefully, the error message states

Re: [HACKERS] Wire protocol compression

On 04/21/2016 03:04 PM, Aleksander Alekseev wrote: I guess since the usual answer for compression was "use what SSL provides you for free", it's rather unlikely that someone bothered to make a proxy just for that purpose, and really, a proxy is just another moving part in your setup: not everyone

Re: [HACKERS] Refactor pg_dump as a library?

On 04/14/2016 07:28 PM, David Steele wrote: As far as I know pg_dump share locks everything before it starts so there shouldn't be issues with concurrent DDL. Try creating a new inherited table with FKs, etc. during a pg_dump and you'll see lots of fun lock waits. I am pretty sure that it does

Re: [HACKERS] Refactor pg_dump as a library?

On 04/14/2016 12:22 PM, Craig Ringer wrote: I'd find a pg_get_tabledef(...) built-in function more interesting for this particular purpose than pg_dump as a library would be. We already have pg_get_viewdef(...), pg_get_functiondef(...) etc. I am personally not a fan of the pg_get_Xdef() functio

Re: [HACKERS] 2016-03 Commitfest

On 04/11/2016 01:35 PM, David Steele wrote: I've marked this committed so the 2016-03 CF is now complete! Thanks to you and everyone else involved in running this CF. You did an excellent job. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

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

Hi, I have an updated patch which uses Matches() rather than TailMatches(). Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index b5117d4..158b913 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/tab-complete.c @@ -1934,12 +1934,19 @@ psql_completion(con

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/04/2016 07:26 AM, Michael Paquier wrote: You may want to use Matches() instead of TailMatches() for performance reasons. Here is an updated version which uses Matches(). Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index 4d2bee1..34dabc5 100644 --- a/src

Re: [HACKERS] Making tab-complete.c easier to maintain

On 01/06/2016 01:13 AM, Michael Paquier wrote: On Wed, Jan 6, 2016 at 2:03 AM, Tom Lane wrote: I've pushed the second patch now. I made a few adjustments --- notably, I didn't like the way you'd implemented '*' wildcards, because they wouldn't have behaved very sanely in combination with '|'.

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/04/2016 07:26 AM, Michael Paquier wrote: You may want to use Matches() instead of TailMatches() for performance reasons. Probably, but if so should we not also change the surrounding rules to also use Matches()? I imitated the surrounding code to keep code consistency and avoid errors.

Re: [HACKERS] \x auto and EXPLAIN

On 01/03/2016 06:43 PM, Tom Lane wrote: I see two ways to fix this. 1) Never use expanded display for the case where there is only one column. There seems to me like there is little value in using expanded display for when you only have one column, but I may be missing some use case here. 2

[HACKERS] \x auto and EXPLAIN

Hi, psql's "\x auto" is a nice feature, but it is made much less useful in my opinion due to the expanded output format making query plans unreadable (and query plans often end up using expanded display due to their width). I think we should never use the expanded format for EXPLAIN output in

[HACKERS] Improved tab completion for FDW DDL

Hi, Here is a patch which adds the below missing tab completions for the FDW DDL commands. I noticed these were missing while playing around with FDWs a while ago. "ALTER SERVER " with "RENAME TO" "CREATE SERVER FOREIGN DATA WRAPPER" with fdw name "CREATE|ALTER USER MAPPING FOR SERVER " wit

[HACKERS] COPY (... tab completion

Hi, Here is a patch which adds tab completion for COPY with a query. Currently there is only completion for COPY with a relation. Andreas diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index 98884eb..98023ca 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/ta

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On 12/14/2015 01:57 PM, Merlin Moncure wrote: This may be moot; some testing demonstrated that libedit was not impacted so it really comes down to having the right readline api call available. Looking at the code ISTM that libedit resets the terminal on every prompt. Did you manage to figure o

[HACKERS] Check for interrupts in bf and xdes crypt()

Hi, Here is a patch which makes it possible to cancel a query which runs the crypt() function with the bf or xdes hashing algorithm, e.g. crypt('foo', gen_salt('bf', 13)). The md5 algorithm does not run for multiple rounds so there is no reason to patch it. I noticed this problem when I acci

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

Hi, I have reviewed this patch and it still applies to master, compiles and passes the test suite. I like the goal of the patch, making use of the already existing abbreviation machinery in more cases is something we should do and the patch itself looks clean. I can also confirm the roughl

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

On 08/26/2015 07:46 AM, Michael Paquier wrote: On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier wrote: On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote: [...] So I think the way to move this forward is to investigate how to hold the SSL config constant until SIGHUP in an EXEC_BACKEND build.

Re: [HACKERS] Commitfest remaining "Needs Review" items

On 08/31/2015 03:34 PM, Alexander Korotkov wrote: +1 for making these dates more explicit Yeah, I think being explicit would make life easier for newcomers. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgres

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

On 08/26/2015 03:57 AM, Tom Lane wrote: Is it unreasonable of me to ask for the Windows behavior to be fixed at the same time? I dunno. It's perhaps less broken than the Unix behavior, but that doesn't make it desirable. OTOH it might be a significantly larger patch, and I confess I'm not even

Re: [HACKERS] Commitfest remaining "Needs Review" items

with the patch. I do not really see what more I can do here other than resubmit it to the next CF which I feel would be poor etiquette by me. If you have the time I to spare I would be very grateful if you could clarify what work you think needs to be done. -- Andreas Karlsson -- Sent via

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

On 07/15/2015 09:30 PM, Robert Haas wrote: On Tue, Jul 14, 2015 at 5:57 PM, Jim Nasby wrote: On 7/7/15 7:07 AM, Andres Freund wrote: On 2015-07-03 18:03:58 -0400, Tom Lane wrote: I have just looked through this thread, and TBH I think we should reject this patch altogether --- not RWF, but "n

Re: [HACKERS] Proposal: backend "niceness" / session_priority

On 07/31/2015 12:18 AM, Jim Nasby wrote: This has been proposed before, and rejected before, and I'm not seeing anything particularly new here. Without a credible mechanism for throttling I/O, "nice" alone does not seem very promising. Some OSes respect nice when it comes to IO scheduling, so

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

On 07/29/2015 03:24 AM, Tom Lane wrote: Peter Eisentraut writes: I don't have a problem with rebuilding the SSL context on every reload cycle. We already do a lot of extra reloading every time, so a bit more shouldn't hurt. But I'm not so sure whether we should do that in the SIGHUP handler.

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On 07/30/2015 04:48 AM, Michael Paquier wrote: On Thu, Jul 30, 2015 at 5:54 AM, Andreas Karlsson wrote: What I do not like though is how the path src/test/tables_fk/t/ tells us nothing about what features are of PostgreSQL are tested here. For this I personally prefer the earlier versions

Re: [HACKERS] Improving test coverage of extensions with pg_dump

I have reviewed this patch and it compiles runs and the new test case passes. The code is also clean and the test seems like a useful regression test. What I do not like though is how the path src/test/tables_fk/t/ tells us nothing about what features are of PostgreSQL are tested here. For thi

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

On 07/23/2015 07:19 AM, Michael Paquier wrote: On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson wrote: On 07/02/2015 06:13 PM, Peter Eisentraut wrote: I think this would be a useful feature, and the implementation looks sound. But I don't like how the reload is organized. Reinitial

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

On 07/02/2015 06:13 PM, Peter Eisentraut wrote: I think this would be a useful feature, and the implementation looks sound. But I don't like how the reload is organized. Reinitializing the context in the sighup handler, aside from questions about how much work one should do in a signal handler,

Re: [HACKERS] PoC: Partial sort

On 09/15/2014 01:58 PM, Alexander Korotkov wrote: On Sun, Sep 14, 2014 at 9:32 AM, Peter Geoghegan mailto:p...@heroku.com>> wrote: I think we might be better off if a tuplesort function was called shortly after tuplesort_begin_heap() is called. How top-n heap sorts work is something

Re: [HACKERS] Fix autoconf deprecation warnings

I have attached new versions which apply on the current master. Andreas >From a4a4970d37b710449ccd57a8b4d896a3c004b62a Mon Sep 17 00:00:00 2001 From: Andreas Karlsson Date: Thu, 12 Feb 2015 23:55:01 +0100 Subject: [PATCH 1/4] Replace obsolete macros AC_TRY_* with AC_*_IFELSE. The AC_T

<    1   2   3   4   >