Re: [HACKERS] [PATCH] Warn users about duplicate configuration parameters

On 2017-04-07 18:29:40 +0300, Aleksander Alekseev wrote: > Andres, Tatsuo, > > Thank you for sharing your thoughts. > > > -1 - I frequently just override earlier parameters by adding an > > include at the end of the file. Also, with postgresql.auto.conf it's > > even more common to override para

Re: [HACKERS] [PATCH] Warn users about duplicate configuration parameters

Andres, Tatsuo, Thank you for sharing your thoughts. > -1 - I frequently just override earlier parameters by adding an > include at the end of the file. Also, with postgresql.auto.conf it's > even more common to override parameters. > -1 from me too by the same reason Andres said. I see no pro

Re: [HACKERS] [PATCH] Warn users about duplicate configuration parameters

>> Recently I've discovered that if there are multiple values of the same >> parameter in postgresql.conf PostgreSQL will silently use the last one. >> It looks like not the best approach to me. For instance, user can find >> the first value in the config file and expect that it will be used, etc.

Re: [HACKERS] [PATCH] Warn users about duplicate configuration parameters

On 2017-04-07 18:14:27 +0300, Aleksander Alekseev wrote: > Hi. > > Recently I've discovered that if there are multiple values of the same > parameter in postgresql.conf PostgreSQL will silently use the last one. > It looks like not the best approach to me. For instance, user can find > the first v

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

On 2017-04-07 13:00:39 +0200, Magnus Hagander wrote: > Insurmountable, probably not. The big difference is that you don't need > *any* dependencies to build a libpq using win32.mak, but you need many of > them (to start with, perl...) to build using the built-in one. For people > who want to build

[HACKERS] [PATCH] Warn users about duplicate configuration parameters

Hi. Recently I've discovered that if there are multiple values of the same parameter in postgresql.conf PostgreSQL will silently use the last one. It looks like not the best approach to me. For instance, user can find the first value in the config file and expect that it will be used, etc. I sugg

Re: [HACKERS] Supporting huge pages on Windows

On 2017-04-07 13:57:07 +0200, Magnus Hagander wrote: > On Wed, Apr 5, 2017 at 9:15 AM, Tsunakawa, Takayuki < > tsunakawa.ta...@jp.fujitsu.com> wrote: > > > From: pgsql-hackers-ow...@postgresql.org > > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andres Freund > > > As I asked before,

Re: [HACKERS] Parallel Append implementation

Hi, On 2017-04-07 11:44:39 +0530, Amit Khandekar wrote: > On 6 April 2017 at 07:33, Andres Freund wrote: > > On 2017-04-05 14:52:38 +0530, Amit Khandekar wrote: > >> This is what the earlier versions of my patch had done : just add up > >> per-subplan parallel_workers (1 for non-partial subplan a

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Mar 29, 2017 at 11:14 PM, Masahiko Sawada wrote: > On Wed, Mar 22, 2017 at 2:49 AM, Masahiko Sawada > wrote: >> On Thu, Mar 16, 2017 at 2:37 PM, Vinayak Pokale >> wrote: >>> The following review has been posted through the commitfest application: >>> make installcheck-world: tested, pa

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

On 04/07/2017 09:58 AM, Tom Lane wrote: >> This seems be the same as the 2nd error that was reported back in 2013: >> https://www.postgresql.org/message-id/CAJ2%3DPVQcW8UGNnSy%3DOw%3DvUK2zpjowTkzUS1B864REa7LOT140Q%40mail.gmail.com. > Well, if it's been broken since (at least) 2013, and we've had

Re: [HACKERS] [PATCH] Document the order of changing certain settings when using hot-standby servers

Hi Yorick, > Attached is an updated version of the patch that corrects the order in > the documentation. Looks promising. I would recommend to add this patch to the next commitfest [1]. Otherwise there is a chance that it will be lost. [1] https://commitfest.postgresql.org/14/ -- Best regards,

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

Heikki Linnakangas writes: > I just tested it. After adding all the missing files to the makefile, > I'm getting an error: >> .\Release\libpq.dll.manifest : general error c1010070: Failed to load and >> parse >> the manifest. The system cannot find the file specified. > This seems be the same

Re: [HACKERS] postgres_fdw: support parameterized foreign joins

On 05.04.2017 12:20, Etsuro Fujita wrote: Rebased. Attached is an updated version created on top of the latest patch "epqpath-for-foreignjoin" [1]. Other changes: * Added a bit more regression tests with FOR UPDATE clause to see if CreateLocalJoinPath works well for parameterized foreign join

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

On 04/07/2017 02:00 PM, Magnus Hagander wrote: On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane wrote: Yeah. For win32.mak, the key question is whether there is still anybody who'd have an insurmountable problem with building the whole distro via src/tools/msvc/ rather than just building libpq with w

Re: [HACKERS] [PATCH] Document the order of changing certain settings when using hot-standby servers

Ha! It seems I indeed had it the other way around. I suppose that's what happens when writing a patch late at night. Somewhat ironically I did have the other correct in my Git commit message. Attached is an updated version of the patch that corrects the order in the documentation. Yorick diff --g

Re: [HACKERS] [PATCH] Document the order of changing certain settings when using hot-standby servers

Aleksander, Yorick, * Aleksander Alekseev (a.aleks...@postgrespro.ru) wrote: > > The attached patch updates the hot-standby documentation (in the high > > availability section) so it explicitly mentions that certain settings > > need to be applied to servers in a particular order. For example, it

Re: [HACKERS] [PATCH] Document the order of changing certain settings when using hot-standby servers

Hi Yorick, > The attached patch updates the hot-standby documentation (in the high > availability section) so it explicitly mentions that certain settings > need to be applied to servers in a particular order. For example, it > states that if you increase a certain setting (e.g. max_connections) >

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

On Fri, Apr 7, 2017 at 8:58 PM, Heikki Linnakangas wrote: > On 04/07/2017 05:30 AM, Michael Paquier wrote: >> I am really wondering if this should not reflect the real range >> reported by the RFC. I understand that you have grouped things to save >> a couple of bytes, but that would protect from

[HACKERS] [PATCH] Document the order of changing certain settings when using hot-standby servers

The attached patch updates the hot-standby documentation (in the high availability section) so it explicitly mentions that certain settings need to be applied to servers in a particular order. For example, it states that if you increase a certain setting (e.g. max_connections) you need to do so on

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

On 04/07/2017 05:30 AM, Michael Paquier wrote: On Fri, Apr 7, 2017 at 2:47 AM, Heikki Linnakangas wrote: On 04/06/2017 08:42 PM, Heikki Linnakangas wrote: There is for example this portion in the new tables: +static const Codepoint prohibited_output_chars[] = +{ + 0xD800, 0xF8FF,

Re: [HACKERS] Supporting huge pages on Windows

On Wed, Apr 5, 2017 at 9:15 AM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andres Freund > > As I asked before, why can't we delete all privs and add the explicitly > > needed

Re: [HACKERS] SCRAM authentication, take three

On 07/04/17 11:05, Magnus Hagander wrote: On Fri, Apr 7, 2017 at 9:59 AM, Heikki Linnakangas > wrote: On 04/07/2017 10:38 AM, Magnus Hagander wrote: So here's a wild idea. What if we just call it "sha256"? Does the user actually care about i

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane wrote: > Andres Freund writes: > > On 2017-04-07 13:07:59 +0900, Michael Paquier wrote: > >> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote: > >>> Still, it's not very clear why we need to cater for building just libpq > >>> rather than the whole distrib

Re: [HACKERS] Declarative partitioning - another take

On 07.04.2017 13:05, Etsuro Fujita wrote: On 2016/12/14 16:20, Etsuro Fujita wrote: On 2016/12/09 19:46, Maksim Milyutin wrote: I would like to work on two tasks: - insert (and eventually update) tuple routing for foreign partition. - the ability to create an index on the parent and have all

[HACKERS] pg_export_snapshot doc

pg_export_snapshot() cannot be used during recovery (i.e. on standby servers), but it's not documented. IMO this is a bug and should be fixed. Patch attached. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp diff --git

[HACKERS] Performance issue with postgres9.6

Hello, We currently use psotgres 9.3 in our products. Recently we upgraded to postgres 9.6. But with 9.6 we have seen a drastic reduction in throughput. After analyzing carefully I found that "planner time" in 9.6 is very high. Below are the details: Scenario: 1 Create a table with 10 rows. 2

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/14 16:20, Etsuro Fujita wrote: On 2016/12/09 19:46, Maksim Milyutin wrote: I would like to work on two tasks: - insert (and eventually update) tuple routing for foreign partition. - the ability to create an index on the parent and have all of the children inherit it; The first one

[HACKERS] ExecPrepareExprList and per-query context

As of b8d7f053c5c, ExecPrepareExprList is (must be?) used instead of ExecPrepareExpr when the caller wants to initialize expressions in a list, for example, FormIndexDatum. ExecPrepareExpr doesn't require the caller to have switched to per-query context, because it itself will. Same is not howeve

Re: [HACKERS] pgbench - allow to store select results into variables

If I understand correctly, the patch is moved because of the unrelated issue that variables cannot be utf8 in pgbench, and it is a condition to consider this patch that existing pgbench variables (set with \set) can be utf8? I'm not sure if it is "unrelated" because the new feature relies on e

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 04/07/2017 11:57 AM, Craig Ringer wrote: On 7 April 2017 at 16:33, Heikki Linnakangas wrote: That list of supported authentication methods would need to be included in the startup message. Unfortunately, there is no way to add options to the startup message, without breaking compatibility w

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Thu, Apr 6, 2017 at 4:12 AM, Andres Freund wrote: > On 2017-03-13 18:45:00 +0530, Mithun Cy wrote: >> I have implemented a similar logic now. The prewarm bgworker will >> launch a sub-worker per database in the dump file. And, each >> sub-worker will load its database block info. The sub-worker

Re: [HACKERS] SCRAM authentication, take three

On Fri, Apr 7, 2017 at 9:59 AM, Heikki Linnakangas wrote: > On 04/07/2017 10:38 AM, Magnus Hagander wrote: > >> So here's a wild idea. What if we just call it "sha256"? Does the user >> actually care about it being scram, or is scram just an implementation >> detail for them? That way when the ne

Re: [HACKERS] SCRAM authentication, take three

On 7 April 2017 at 15:59, Heikki Linnakangas wrote: > On 04/07/2017 10:38 AM, Magnus Hagander wrote: >> Not sure if it would be doable in the code, but we could also have: >> host all all example.com scram method=sha256plus,sha256 >> >> or something like that. Which would fit within the current s

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 7 April 2017 at 16:33, Heikki Linnakangas wrote: > That list of supported authentication methods would need to be included in > the startup message. Unfortunately, there is no way to add options to the > startup message, without breaking compatibility with old servers. If there > is an option

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 04/06/2017 11:05 PM, Tom Lane wrote: Perhaps we could turn this around: have the client send (in the connection request packet) a list of auth protocols it thinks it is able to handle. (I'm envisioning this as being more or less fixed for any one version of any one client, since it would basic

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 04/06/2017 11:16 PM, Simon Riggs wrote: or it can just ignore the list and send what it wants anyway, probably leading to client disconnect. It would need to follow one of the requested protocols, but mark the request as doomed. Otherwise we'd be revealing information. That's what SCRAM does

Re: [HACKERS] pgbench - allow to store select results into variables

> If I understand correctly, the patch is moved because of the unrelated > issue that variables cannot be utf8 in pgbench, and it is a condition > to consider this patch that existing pgbench variables (set with \set) > can be utf8? I'm not sure if it is "unrelated" because the new feature relies

Re: [HACKERS] SCRAM authentication, take three

On 04/07/2017 10:38 AM, Magnus Hagander wrote: So here's a wild idea. What if we just call it "sha256"? Does the user actually care about it being scram, or is scram just an implementation detail for them? That way when the next one shows up, it'll be sha512 or whatever. It happens to use scram u

Re: [HACKERS] Compiler warning in costsize.c

On Fri, Apr 7, 2017 at 12:38 AM, Michael Paquier wrote: > On Tue, Apr 4, 2017 at 9:42 PM, Michael Paquier > wrote: >> On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote: >>> (I'm personally not that much in love with PG_USED_FOR_ASSERTS_ONLY, >>> because it tends to confuse pgindent.) >> >> I would

Re: [HACKERS] pgbench - allow to store select results into variables

Hello Tatsuo, Ok, I will move the patch to the next cf. Done. If I understand correctly, the patch is moved because of the unrelated issue that variables cannot be utf8 in pgbench, and it is a condition to consider this patch that existing pgbench variables (set with \set) can be utf8?

Re: [HACKERS] Undefined psql variables

Hello Corey, \if defined varname \if sql boolean expression to send to server \if compare value operator value I'm still thinking:-) Independently of the my aethetical complaint against having a pretty unusual keyword prefix syntax, how would you envision a \set assig

Re: [HACKERS] Compiler warning in costsize.c

On Tue, Apr 4, 2017 at 9:42 PM, Michael Paquier wrote: > On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote: >> (I'm personally not that much in love with PG_USED_FOR_ASSERTS_ONLY, >> because it tends to confuse pgindent.) > > I would be incline to just do that, any other solution I can think of > is

Re: [HACKERS] SCRAM authentication, take three

Jumping late into this one, apologies if these opinions have already been up and discarded. On Fri, Apr 7, 2017 at 9:28 AM, Heikki Linnakangas wrote: > On 04/07/2017 08:21 AM, Noah Misch wrote: > >> On Thu, Apr 06, 2017 at 09:46:29PM +0300, Heikki Linnakangas wrote: >> >>> On 04/06/2017 08:36 AM

Re: [HACKERS] Comment typo in publicationcmd.c

On Fri, Apr 7, 2017 at 9:00 AM, Masahiko Sawada wrote: > Hi all, > > Attached fixes a typo in publicationcmd.c file. > > s/om/on/ > Applied, thanks. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] SCRAM authentication, take three

On 04/07/2017 08:21 AM, Noah Misch wrote: On Thu, Apr 06, 2017 at 09:46:29PM +0300, Heikki Linnakangas wrote: On 04/06/2017 08:36 AM, Noah Misch wrote: On Tue, Mar 07, 2017 at 02:36:13PM +0200, Heikki Linnakangas wrote: I didn't include the last-minute changes to the way you specify this in pg

[HACKERS] Comment typo in publicationcmd.c

Hi all, Attached fixes a typo in publicationcmd.c file. s/om/on/ Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center fix_typo_in_publicationcmds_c.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] increasing the default WAL segment size

I ran tests and following are the details: Machine details: Architecture: ppc64le Byte Order:Little Endian CPU(s):192 On-line CPU(s) list: 0-191 Thread(s) per core:8 Core(s) per socket:1 Socket(s): 24 NUMA node(s): 4 Model:

<    1   2