Fix obsolete comment

Hi. A comment in ExecUpdate refers to an argument of ExecConstraints that no longer exists. Attached fixes that, but I'm about over a year too late [1] in sending this patch. Thanks, Amit [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c0a8ae7be392 diff --git a/src/backen

RE: I'd like to discuss scaleout at PGCon

> From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru] > I can not completely agree with it. I have done a lot of benchmarking of > PostgreSQL, CitusDB, SparkSQL and native C/Scala code generated for > TPC-H queries. Wow, you have an amazingly abundant experience. > I do not want to say

RE: I'd like to discuss scaleout at PGCon

From: Michael Paquier [mailto:mich...@paquier.xyz] > > On Wed, Jun 6, 2018 at 8:16 PM, MauMau wrote: > >> Looking at the XL source code, the following sequence of functions > >> are called when the coordinator handles the Row Description message > >> ('T') from the data node. I guess the parsing

Re: Concurrency bug in UPDATE of partition-key

On Tue, Jun 5, 2018 at 8:03 PM, Amit Khandekar wrote: > Attached is a rebased patch version. Also included it in the upcoming > commitfest : > https://commitfest.postgresql.org/18/1660/ > > Doesn't this belong to PostgreSQL 11 Open Items [1] or are you proposing it as a feature enhancement for ne

Re: Needless additional partition check in INSERT?

On 7 June 2018 at 17:45, Amit Langote wrote: > On 2018/06/07 13:10, David Rowley wrote: >> On 7 June 2018 at 16:05, Amit Langote wrote: >>> Or we could just not have a separate function and put the logic that >>> determines whether or not to check the partition constraint right before >>> the fol

Re: Needless additional partition check in INSERT?

On 2018/06/07 13:10, David Rowley wrote: > On 7 June 2018 at 16:05, Amit Langote wrote: >> Or we could just not have a separate function and put the logic that >> determines whether or not to check the partition constraint right before >> the following piece of code in ExecConstraints >> >> if

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/07 14:17, Ashutosh Bapat wrote: >> that is, users can find out about that feature by themselves by >> trying it out? > > I didn't understand that part. > > Probably we just say that BEFORE ROW triggers are not supported on a > partitioned table. It's good enough not to suggest it ourse

Re: I'd like to discuss scaleout at PGCon

On Thu, Jun 7, 2018 at 10:53 AM, Michael Paquier wrote: > On Thu, Jun 07, 2018 at 10:28:15AM +0530, Ashutosh Bapat wrote: >> On Wed, Jun 6, 2018 at 8:16 PM, MauMau wrote: >>> Looking at the XL source code, the following sequence of functions are >>> called when the coordinator handles the Row Des

Re: I'd like to discuss scaleout at PGCon

On Thu, Jun 07, 2018 at 10:28:15AM +0530, Ashutosh Bapat wrote: > On Wed, Jun 6, 2018 at 8:16 PM, MauMau wrote: >> Looking at the XL source code, the following sequence of functions are >> called when the coordinator handles the Row Description message ('T') >> from the data node. I guess the par

Re: why partition pruning doesn't work?

On Thu, Jun 7, 2018 at 8:51 AM, David Rowley wrote: > On 7 June 2018 at 14:51, Amit Langote wrote: >> Thanks David. This one looks good. I also like it that hasparamlessexprs >> is no longer determined and set in the planner. > > Thanks for checking it. > >> I checked what happens with the case

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On Thu, Jun 7, 2018 at 7:51 AM, Amit Langote wrote: > On 2018/06/06 20:51, Ashutosh Bapat wrote: >> The existing wording suggests that the user >> creates the triggers on the partitioned table, and that will be >> supported always, which can lead to problems. > > Do you mean the following wording

Re: I'd like to discuss scaleout at PGCon

On Wed, Jun 6, 2018 at 11:46 PM, Alvaro Herrera wrote: > On 2018-Jun-06, Ashutosh Bapat wrote: > >> On Tue, Jun 5, 2018 at 10:04 PM, MauMau wrote: >> > From: Ashutosh Bapat >> >> In order to normalize parse trees, we need to at least replace >> >> various OIDs in parse-tree with something that th

Re: computing completion tag is expensive for pgbench -S -M prepared

On 7 June 2018 at 16:13, Andres Freund wrote: > in PortalRun(). That's actually fairly trivial to optimize - we don't > need the full blown snprintf machinery here. A quick benchmark > replacing it with: > >memcpy(completionTag, "SELECT ", sizeof("SELECT ")); >

Re: I'd like to discuss scaleout at PGCon

On Wed, Jun 6, 2018 at 8:16 PM, MauMau wrote: > From: Ashutosh Bapat >> Keeping OIDs same across the nodes would require extra communication >> between nodes to keep track of next OID, dropped OIDs etc. We need > to >> weigh the time spent in that communication and the time saved during >> parsing

Re: SCRAM with channel binding downgrade attack

On Wed, Jun 06, 2018 at 11:46:11PM +0300, Heikki Linnakangas wrote: > Ok. Perhaps add a comment pointing out that as the code stands, > get_auth_request_str() is never called with AUTH_REQ_OK. So that if someone > starts calling it with that, maybe they'll know to revisit this. That makes sense.

computing completion tag is expensive for pgbench -S -M prepared

Hi, While looking at a profile I randomly noticed that we spend a surprising amount of time in snprintf() and its subsidiary functions. That turns out to be if (strcmp(portal->commandTag, "SELECT") == 0) snprintf(completionTag, COMPLETION_TAG_BUFSIZE,

Re: Needless additional partition check in INSERT?

On 7 June 2018 at 15:57, Alvaro Herrera wrote: > Hm I was thinking this new function would be companion to ExecConstrains > (a fact I used in the name I proposed,) so it'd be in the same file > (probably right after it.) Okay. v5 (attached) does it that way. -- David Rowley h

Re: Needless additional partition check in INSERT?

On 7 June 2018 at 16:05, Amit Langote wrote: > Or we could just not have a separate function and put the logic that > determines whether or not to check the partition constraint right before > the following piece of code in ExecConstraints > > if (check_partition_constraint && resultRelInfo->r

Re: Needless additional partition check in INSERT?

On 2018/06/07 12:57, Alvaro Herrera wrote: > On 2018-Jun-07, David Rowley wrote: >> I'm personally not really for or against having the function. I agree >> that it's slightly weird, but anyway, here's the patch. I'll leave it >> up to you to which one you prefer, v3 or v4. > > Hm I was thinking t

Re: Needless additional partition check in INSERT?

On 2018-Jun-07, David Rowley wrote: > Hi Alvaro, > > Thanks for looking at this. I thought it was strange to pass in both > resultRelInfos. I ended up just making the 2nd param a bool to > indicate of tuple routing was used. Good call. > I'm personally not really for or against having the funct

Re: Loaded footgun open_datasync on Windows

On Wed, Jun 6, 2018 at 3:06 PM, Kuntal Ghosh wrote: > On Wed, Jun 6, 2018 at 2:39 PM, Amit Kapila > wrote: > > On Wed, Jun 6, 2018 at 10:18 AM, Michael Paquier > > wrote: > >> > >> On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote: > >> > >> >> It could be > >> >> risky for existing c

Re: why partition pruning doesn't work?

On 7 June 2018 at 14:51, Amit Langote wrote: > Thanks David. This one looks good. I also like it that hasparamlessexprs > is no longer determined and set in the planner. Thanks for checking it. > I checked what happens with the cases that Ashutosh complained about > upthread and seems that the

Re: commitfest 2018-07

> On Jun 6, 2018, at 8:14 PM, Michael Paquier wrote: > > On Wed, Jun 06, 2018 at 12:40:40PM -0400, Andrew Dunstan wrote: >> I'll volunteer for CFM, which seems appropriate since I was one of the >> supporters of having an extra CF. > > I don't mind helping out either. There are many patches t

Re: why partition pruning doesn't work?

On 2018/06/06 18:52, David Rowley wrote: > On 6 June 2018 at 18:05, Amit Langote wrote: >> On 2018/06/06 14:10, David Rowley wrote: >>> I then decided that >>> I didn't like the way we need to check which params are in the Expr >>> each time we call partkey_datum_from_expr. It seems better to prep

Re: libpq compression

On 7 June 2018 at 04:01, Peter Eisentraut wrote: > On 6/6/18 13:20, Konstantin Knizhnik wrote: > > Well, psql really allows to specify complete connection string with -d > > options (although it is not mentioned in help). > > But still I think that it is inconvenient to require user to write > >

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018/06/06 20:51, Ashutosh Bapat wrote: > The existing wording suggests that the user > creates the triggers on the partitioned table, and that will be > supported always, which can lead to problems. Do you mean the following wording "BEFORE ROW triggers, if necessary, must be defined on indiv

Re: pg_replication_slot_advance to return NULL instead of 0/0 if slot not advanced

On Wed, Jun 06, 2018 at 04:57:22PM +0200, Petr Jelinek wrote: > I think the only thing to note about the patches from my side is that we > probably don't want to default to restart_lsn for the > pg_logical_replication_slot_advance() return value (when nothing was > done) but rather the confirmed_ls

Re: Spilling hashed SetOps and aggregates to disk

On 6 June 2018 at 01:17, David Rowley wrote: > On 6 June 2018 at 01:09, Andres Freund wrote: >> On 2018-06-06 01:06:39 +1200, David Rowley wrote: >>> My concern is that only accounting memory for the group and not the >>> state is only solving half the problem. It might be fine for >>> aggregates

Re: Spilling hashed SetOps and aggregates to disk

On 2018-06-06 17:17:52 -0700, Andres Freund wrote: > On 2018-06-07 12:11:37 +1200, David Rowley wrote: > > On 7 June 2018 at 08:11, Tomas Vondra wrote: > > > On 06/06/2018 04:11 PM, Andres Freund wrote: > > >> Consider e.g. a scheme where we'd switch from hashed aggregation to > > >> sorted aggreg

Re: Spilling hashed SetOps and aggregates to disk

On 2018-06-07 12:11:37 +1200, David Rowley wrote: > On 7 June 2018 at 08:11, Tomas Vondra wrote: > > On 06/06/2018 04:11 PM, Andres Freund wrote: > >> Consider e.g. a scheme where we'd switch from hashed aggregation to > >> sorted aggregation due to memory limits, but already have a number of > >>

Re: Spilling hashed SetOps and aggregates to disk

On 06/07/2018 02:11 AM, David Rowley wrote: > On 7 June 2018 at 08:11, Tomas Vondra wrote: >> On 06/06/2018 04:11 PM, Andres Freund wrote: >>> Consider e.g. a scheme where we'd switch from hashed aggregation to >>> sorted aggregation due to memory limits, but already have a number of >>> transi

Re: commitfest 2018-07

On Wed, Jun 06, 2018 at 12:40:40PM -0400, Andrew Dunstan wrote: > I'll volunteer for CFM, which seems appropriate since I was one of the > supporters of having an extra CF. I don't mind helping out either. There are many patches to handle. -- Michael signature.asc Description: PGP signature

Re: Spilling hashed SetOps and aggregates to disk

On 7 June 2018 at 08:11, Tomas Vondra wrote: > On 06/06/2018 04:11 PM, Andres Freund wrote: >> Consider e.g. a scheme where we'd switch from hashed aggregation to >> sorted aggregation due to memory limits, but already have a number of >> transition values in the hash table. Whenever the size of t

Re: Needless additional partition check in INSERT?

On 7 June 2018 at 09:08, Alvaro Herrera wrote: > I wonder if we should create a new small function that takes the two > resultRelInfos and returns the correct boolean --maybe something like > ExecConstraintsPartConstrNeedsRecheck()-- and then the smarts are in a > single place and we diminish the

Re: POC: GROUP BY optimization

On Wed, Jun 6, 2018 at 8:06 PM Tomas Vondra wrote: > >>> Comparison cost can be approximated probabilistically as: > >>> > >>> cost_comp = sum(cost_op_n * (1.0 / ndistinct(col_1_to_n))) > >>> > >>> Where cost_op_n is the cost of the comparison function for column N, > >>> and ndistinct(col_1_to_n)

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Andres Freund writes: > On 2018-06-06 21:25:14 +0100, Andrew Gierth wrote: >> The obvious case which is not one of those "pretty much all cases" is >> where DirectFunctionCallN[Coll] is used - which turns out to be not all >> that unusual. > There the callsite just lives for just one call, I don'

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Hi, On 2018-06-06 21:25:14 +0100, Andrew Gierth wrote: > > "Andres" == Andres Freund writes: > > Andres> I think it's not unreasonable to think of it that way, but it's > Andres> really not how it is used today. In pretty much all cases the > Andres> collation is known and determined at t

Re: POC: GROUP BY optimization

On 06/07/2018 12:18 AM, Claudio Freire wrote: > On Wed, Jun 6, 2018 at 6:57 PM Tomas Vondra > wrote: >> >> On 06/06/2018 11:22 PM, Claudio Freire wrote: >>> On Wed, Jun 6, 2018 at 5:43 PM Tomas Vondra >>> As such, estimating sort performance correctly in the various plan >>> variants being consi

Re: I'd like to discuss scaleout at PGCon

From: Alvaro Herrera > Maybe an easy (hah) thing to do is use 2PC for DDL, agree on a OID > that's free on every node, then create the object in all servers at the > same time. We currently use the system-wide OID generator to assign the > OID, but seems an easy thing to change (much harder is to

Re: I'd like to discuss scaleout at PGCon

From: Alvaro Herrera > Maybe an easy (hah) thing to do is use 2PC for DDL, agree on a OID > that's free on every node, then create the object in all servers at the > same time. We currently use the system-wide OID generator to assign the > OID, but seems an easy thing to change (much harder is to

Re: POC: GROUP BY optimization

On Wed, Jun 6, 2018 at 7:18 PM Claudio Freire wrote: > > > Comparison cost can be approximated probabilistically as: > > > > > > cost_comp = sum(cost_op_n * (1.0 / ndistinct(col_1_to_n))) > > > > > > Where cost_op_n is the cost of the comparison function for column N, > > > and ndistinct(col_1_to_

Re: POC: GROUP BY optimization

On Wed, Jun 6, 2018 at 6:57 PM Tomas Vondra wrote: > > On 06/06/2018 11:22 PM, Claudio Freire wrote: > > On Wed, Jun 6, 2018 at 5:43 PM Tomas Vondra > > As such, estimating sort performance correctly in the various plan > > variants being considered seems to be a very central aspect of it. > > > >

Re: SCRAM with channel binding downgrade attack

On Wed, Jun 06, 2018 at 11:53:06PM +0300, Heikki Linnakangas wrote: > That would certainly be good. We've always had that problem, even with md5 > -> plaintext password downgrade, and it would be nice to fix it. It's quite > late in the release cycle already, do you think we should address that now

Re: POC: GROUP BY optimization

On 06/06/2018 11:22 PM, Claudio Freire wrote: > On Wed, Jun 6, 2018 at 5:43 PM Tomas Vondra > wrote: >> >> For example, it seems to disregard that different data types have >> different comparison costs. For example comparing bytea will be far >> more expensive compared to int4, so it

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 6, 2018 at 2:21 PM Michael Paquier wrote: Thanks for the pointers, Steven. You should avoid top-posting on this > list, this is not the style used on the Postgres lists. > Ah sorry about that! Hopefully this looks better. > Does this mean that tls-server-end-point goes into unsupp

Re: POC: GROUP BY optimization

On Wed, Jun 6, 2018 at 5:43 PM Tomas Vondra wrote: > > For example, it seems to disregard that different data types have > different comparison costs. For example comparing bytea will be far > more expensive compared to int4, so it may be much more efficient to > compare int4 c

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 06, 2018 at 01:16:11PM -0700, Steven Fackler wrote: Thanks for the pointers, Steven. You should avoid top-posting on this list, this is not the style used on the Postgres lists. > TLS 1.3, (which is currently in a draft state, but is theoretically being > finalized soon) does not sup

Re: Needless additional partition check in INSERT?

On 2018-May-10, David Rowley wrote: > Yeah, the comments do need work. In order to make it a bit easier to > document I changed the way that check_partition_constr is set. This is > now done with an if/else if/else clause for both COPY and INSERT. > > Hopefully, that's easier to understand and pr

Re: SCRAM with channel binding downgrade attack

On 06/06/18 23:31, Peter Eisentraut wrote: On 6/6/18 16:26, Heikki Linnakangas wrote: On 06/06/18 23:20, Peter Eisentraut wrote: Aren't we attacking this on the wrong level? We are here attempting to prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not preventing a SCRAM-SHA

Re: SCRAM with channel binding downgrade attack

On 05/06/18 09:41, Michael Paquier wrote: On Sat, Jun 02, 2018 at 01:08:56PM -0400, Heikki Linnakangas wrote: On 28/05/18 15:08, Michael Paquier wrote: On Mon, May 28, 2018 at 12:26:37PM +0300, Heikki Linnakangas wrote: + printfPQExpBuffer(&conn->errorMessage, +libpq_gettext("channel bindi

Re: POC: GROUP BY optimization

On 06/06/2018 08:04 PM, Teodor Sigaev wrote: > >>> problem 2). Index optimization was noticed by me later. But based on >>> your suggested patch's order I split the patch to index and non-index >>> part and second part depends of first one. They touch the same part >>> of code and they could not b

Re: SCRAM with channel binding downgrade attack

On 6/6/18 16:26, Heikki Linnakangas wrote: > On 06/06/18 23:20, Peter Eisentraut wrote: >> Aren't we attacking this on the wrong level? We are here attempting to >> prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not >> preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade

Re: SCRAM with channel binding downgrade attack

On 06/06/18 23:20, Peter Eisentraut wrote: Aren't we attacking this on the wrong level? We are here attempting to prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade. The latest patch does prevent that, too. That wa

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

> "Andres" == Andres Freund writes: Andres> I think it's not unreasonable to think of it that way, but it's Andres> really not how it is used today. In pretty much all cases the Andres> collation is known and determined at the time fmgr_info() is Andres> called (we also commonly reuse Fun

Re: SCRAM with channel binding downgrade attack

Aren't we attacking this on the wrong level? We are here attempting to prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Sup

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

TLS 1.3, (which is currently in a draft state, but is theoretically being finalized soon) does not support the TLS channel binding algorithms [1]. >From talking with one of the people working on the TLS 1.3 standard, tls-unique is seen as particularly problematic. There's some discussion on the IET

libpq compression

On Wednesday, June 6, 2018, Peter Eisentraut wrote: > On 6/6/18 13:20, Konstantin Knizhnik wrote: > > Well, psql really allows to specify complete connection string with -d > > options (although it is not mentioned in help). > > But still I think that it is inconvenient to require user to write >

Re: Spilling hashed SetOps and aggregates to disk

On 06/06/2018 04:11 PM, Andres Freund wrote: > On 2018-06-06 16:06:18 +0200, Tomas Vondra wrote: >> On 06/06/2018 04:01 PM, Andres Freund wrote: >>> Hi, >>> >>> On 2018-06-06 15:58:16 +0200, Tomas Vondra wrote: The other issue is that serialize/deserialize is only a part of a problem - yo

Re: libpq compression

On 6/6/18 13:20, Konstantin Knizhnik wrote: > Well, psql really allows to specify complete connection string with -d > options (although it is not mentioned in help). > But still I think that it is inconvenient to require user to write > complete connection string to be able to specify compressio

Re: Transform for pl/perl

On 6/6/18 12:14, Alvaro Herrera wrote: > On 2018-May-17, Peter Eisentraut wrote: > >> The items that are still open from the original email are: >> >> 2) jsonb scalar values are passed to the plperl function wrapped in not >>one, but _two_ layers of references >> >> 3) jsonb numeric values are

Re: Bug in either collation docs or code

On 05/06/18 07:10, Melanie Plageman wrote: Hi, I noticed what seems like a bug in collation. This query errors out: SELECT (SELECT 'c' COLLATE "de_DE") > (SELECT 'ç' COLLATE "es_ES"); -- error While this query does not: SELECT 'c' COLLATE "de_DE" > (SELECT 'ç' COLLATE "es_ES"); -- no error I

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 6/6/18 12:37, Alvaro Herrera wrote: > If SCRAM channel binding is an important aspect to security, and the > older OpenSSL versions will still be around in servers for some time > yet, it seems like it behooves us to go the extra mile and provide an > implementation that works with such existing

Re: buildfarm vs code

On 06/06/2018 01:52 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/06/2018 10:24 AM, Tom Lane wrote: I'm curious to know what the failure looks like exactly? [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:7] pg_regress/tablespace ERROR: could not set permissions on directory "C:/projects/

Pushing down join clauses into subqueries

It would be nice, if we could push down join quals into subqueries. For example: create table small_table (i int); create table big_table (i int, j int); insert into small_table values (1), (2); -- two rows insert into big_table select g/10, g from generate_series(1, 10) g; -- million rows

Re: I'd like to discuss scaleout at PGCon

On 2018-Jun-06, Ashutosh Bapat wrote: > On Tue, Jun 5, 2018 at 10:04 PM, MauMau wrote: > > From: Ashutosh Bapat > >> In order to normalize parse trees, we need to at least replace > >> various OIDs in parse-tree with something that the foreign server > >> will understand correctly like table name

Re: POC: GROUP BY optimization

problem 2). Index optimization was noticed by me later. But based on your suggested patch's order I split the patch to index and non-index part and second part depends of first one. They touch the same part of code and they could not be independent The way I see it the patch does two differen

Re: buildfarm vs code

Andrew Dunstan writes: > On 06/06/2018 10:24 AM, Tom Lane wrote: >> I'm curious to know what the failure looks like exactly? > [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:7] pg_regress/tablespace > ERROR: could not set permissions on directory > "C:/projects/pg-devel/src/test/regress/testtabl

Re: buildfarm vs code

On 06/06/2018 10:24 AM, Tom Lane wrote: Andrew Dunstan writes: Yeah, what seems quite odd, though, is that when run as an unprivileged use the tablespace test runs just fine, but when run as a privileged user it fails. If that's fixable we should fix it :-) I'm curious to know what the fail

Re: libpq compression

On 06/06/2018 10:20 AM, Konstantin Knizhnik wrote: Well, psql really allows to specify complete connection string with -d options (although it is not mentioned in help). But still I think that it is inconvenient to require user to write complete connection string to be able to specify compressi

Re: libpq compression

On 06.06.2018 19:33, Konstantin Knizhnik wrote: On 05.06.2018 20:06, Peter Eisentraut wrote: On 6/5/18 03:09, Michael Paquier wrote: I just had a quick look at this patch, lured by the smell of your latest messages...  And it seems to me that this patch needs a heavy amount of work as pre

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Hi, On 2018-06-06 11:17:33 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On 6/6/18 09:06, Andres Freund wrote: > >> FmgrInfo really *is* call-site dependent, no? fn_extra, fn_mcxt, fn_expr > >> all are. I think it's more useful to view the FmgrInfo / > >> FunctionCallInfo data split as t

Re: processSQLNamePattern() analog

Sergey Cherkashin writes: > The command "\dA" (as well as several commands that I write) accept the > access method name template. The resulting template is processed by the > processSQLNamePattern () function, which means that a template with a schema > can be fed to the input. But since the a

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

Alvaro Herrera writes: > If SCRAM channel binding is an important aspect to security, and the > older OpenSSL versions will still be around in servers for some time > yet, it seems like it behooves us to go the extra mile and provide an > implementation that works with such existing servers. Look

Re: commitfest 2018-07

On 06/06/2018 11:57 AM, Jonathan S. Katz wrote: On Jun 5, 2018, at 1:34 PM, Jonathan S. Katz > wrote: On Jun 5, 2018, at 10:14 AM, Tom Lane > wrote: Michael Paquier mailto:mich...@paquier.xyz>> writes: Okay.  If we tend

Re: I'd like to discuss scaleout at PGCon

From: Simon Riggs On 5 June 2018 at 17:14, MauMau wrote: >> Furthermore, an extra hop and double parsing/planning could matter for >> analytic queries, too. For example, SAP HANA boasts of scanning 1 >> billion rows in one second. In HANA's scaleout architecture, an >> application can connect t

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 2018-May-29, Michael Paquier wrote: > On Tue, May 29, 2018 at 10:33:03PM -0400, Heikki Linnakangas wrote: > > Hmm. I think Peter went through this in commits ac3ff8b1d8 and 054e8c6cdb. > > If you got that working now, I suppose we could do that, but I'm actually > > inclined to just stick to th

Re: libpq compression

On 05.06.2018 20:06, Peter Eisentraut wrote: On 6/5/18 03:09, Michael Paquier wrote: I just had a quick look at this patch, lured by the smell of your latest messages... And it seems to me that this patch needs a heavy amount of work as presented. There are a couple of things which are not

Re: Portability concerns over pq_sendbyte?

On 2018-May-24, Andrew Gierth wrote: > In PG11, pq_sendbyte got changed from taking an int parameter to taking > an int8. > Would it be better for these to take unsigned values, or have unsigned > variants? Do you have an answer to this question? Does anybody else? (My guts tell me it'd be bet

Re: Possible bug in logical replication.

This thread seems to have died down without any fix being proposed. Simon, you own this open item. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Transform for pl/perl

On 2018-May-17, Peter Eisentraut wrote: > The items that are still open from the original email are: > > 2) jsonb scalar values are passed to the plperl function wrapped in not >one, but _two_ layers of references > > 3) jsonb numeric values are passed as perl's NV (floating point) type, >

Re: Explain buffers wrong counter with parallel plans

On 2018-May-07, Robert Haas wrote: > On Sat, May 5, 2018 at 8:56 AM, Amit Kapila wrote: > > The reason why I think the current behavior is okay because it is > > coincidental that they were displayed correctly. We have not made any > > effort to percolate it to upper nodes. For ex., before that

Re: file cloning in pg_upgrade and CREATE DATABASE

I have made a major revision of this patch. I have removed all the changes to CREATE DATABASE. That was too contentious and we got lost in unrelated details there. The real benefit is for pg_upgrade. Another point was that for pg_upgrade use a user would like to know beforehand whether reflinki

Re: commitfest 2018-07

> On Jun 5, 2018, at 1:34 PM, Jonathan S. Katz > wrote: > > >> On Jun 5, 2018, at 10:14 AM, Tom Lane wrote: >> >> Michael Paquier writes: >>> Okay. If we tend toward this direction, I propose to do this switch in >>> two days my time (Thursday afternoon in Tokyo) if there are no >>> object

Re: I'd like to discuss scaleout at PGCon

From: Michael Paquier > Greenplum's orca planner (and Citus?) have such facilities if I recall > correctly, just mentioning that pushing down directly to remote nodes > compiled plans ready for execution exists here and there (that's not the > case of XC/XL). For queries whose planning time is way

Re: Scariest patch tournament, PostgreSQL 11 edition

PostgreSQL hackers and community at large, previously I wrote: > In the spirit of the season, the Release Management Team would like to > gather your thoughts on Fear, Risk and Data Corruption for features in > PostgreSQL 11. What patch or patches committed in this cycle do you > think have the h

Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints

[Re-send; first attempt appears to have hit /dev/null somewhere. My apologies if you get two copies.] I've finally gotten around to rebasing this patch and making the change that was requested, which was: merge the now-would-be-three deferral- related bool columns in various pg_catalog tables int

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Peter Eisentraut writes: > On 6/6/18 09:06, Andres Freund wrote: >> FmgrInfo really *is* call-site dependent, no? fn_extra, fn_mcxt, fn_expr >> all are. I think it's more useful to view the FmgrInfo / >> FunctionCallInfo data split as the separation between per-callsite and >> per-call data. And

Re: PATCH pass PGOPTIONS to pg_regress

On 5/29/18 09:19, Manuel Kniep wrote: > Consider something like this in an extensions makefile: > > ifeq ($(shell test $(VERSION_NUM) -ge 90600; echo $$?),0) > PGOPTIONS+= "--max_parallel_workers_per_gather=0" > endif I think you can probably write this inside your test .sql file using a bit of P

Re: pg_replication_slot_advance to return NULL instead of 0/0 if slot not advanced

On 06/06/18 04:04, Michael Paquier wrote: > On Tue, Jun 05, 2018 at 01:00:30PM +0200, Petr Jelinek wrote: >> I didn't say anything about CreateDecodingContext though. I am talking >> about the fact that we then use the same variable as input to >> XLogReadRecord later in the logical slot code pat

Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

On 6/6/18 09:06, Andres Freund wrote: >> It's true that we often abuse fn_extra to hold data that's essentially >> call-site-dependent, but I don't think that's a good reason to push >> collation into FmgrInfo. > FmgrInfo really *is* call-site dependent, no? fn_extra, fn_mcxt, fn_expr > all are. I

Re: I'd like to discuss scaleout at PGCon

From: Ashutosh Bapat > Keeping OIDs same across the nodes would require extra communication > between nodes to keep track of next OID, dropped OIDs etc. We need to > weigh the time spent in that communication and the time saved during > parsing. If we manage the system catalog for cluster-wide obj

Re: buildfarm vs code

Andrew Dunstan writes: > Yeah, what seems quite odd, though, is that when run as an unprivileged > use the tablespace test runs just fine, but when run as a privileged > user it fails. If that's fixable we should fix it :-) I'm curious to know what the failure looks like exactly?

Re: Spilling hashed SetOps and aggregates to disk

On 2018-06-06 16:06:18 +0200, Tomas Vondra wrote: > On 06/06/2018 04:01 PM, Andres Freund wrote: > > Hi, > > > > On 2018-06-06 15:58:16 +0200, Tomas Vondra wrote: > > > The other issue is that serialize/deserialize is only a part of a problem > > > - > > > you also need to know how to do "combine

Re: Spilling hashed SetOps and aggregates to disk

On 06/06/2018 04:01 PM, Andres Freund wrote: Hi, On 2018-06-06 15:58:16 +0200, Tomas Vondra wrote: The other issue is that serialize/deserialize is only a part of a problem - you also need to know how to do "combine", and not all aggregates can do that ... (certainly not in universal way). Th

Re: Spilling hashed SetOps and aggregates to disk

Hi, On 2018-06-06 15:58:16 +0200, Tomas Vondra wrote: > The other issue is that serialize/deserialize is only a part of a problem - > you also need to know how to do "combine", and not all aggregates can do > that ... (certainly not in universal way). There are several schemes where only serializ

Re: Spilling hashed SetOps and aggregates to disk

On 06/05/2018 07:39 PM, David Fetter wrote: On Tue, Jun 05, 2018 at 01:27:01PM -0400, Tom Lane wrote: David Fetter writes: On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote: True. Although not all built in aggregates have those defined. Just out of curiosity, which ones don't

Re: POC: GROUP BY optimization

On 06/05/2018 07:56 PM, Teodor Sigaev wrote: Thanks for the patch. This (missing) optimization popped-up repeatedly recently, and I was planning to look into it for PG12. So now I don't have to, because you've done all the hard work ;-) You are welcome. Actually one of out customers faced the

Re: buildfarm vs code

On 06/06/2018 09:16 AM, Amit Kapila wrote: > The second change the recipe makes is to disable the tablespace tests. On > Windows, when running as the Administrator, the application gives up > privilege to such an extent that the tablespace tests fail. Ohh.  I was confused

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Tue, Jun 5, 2018 at 7:35 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Jun 5, 2018 at 4:02 PM Andres Freund wrote: > > On 2018-06-05 13:09:08 +0300, Alexander Korotkov wrote: > > > It appears that buffer replacement happening inside relation > > > extension lock is affec

Re: buildfarm vs code

On Wed, Jun 6, 2018 at 9:05 AM, Thomas Munro wrote: > On Wed, Jun 6, 2018 at 4:09 AM, Andrew Dunstan > wrote: > > At my talk at pgcon last Friday [1] I presented some ideas for how people > > could run a full buildfarm run against their code, including a 4 line > recipe > > using some Docker rec

  1   2   >