Re: [HACKERS] UPDATE of partition key

On 12 September 2017 at 11:57, Dilip Kumar wrote: > On Tue, Sep 12, 2017 at 11:15 AM, Amit Khandekar > wrote: > >> But the statement level trigger function can refer to OLD TABLE and >> NEW TABLE, which will contain all the OLD rows and NEW rows >> respectively. So the updated rows of the partit

[HACKERS] More efficient truncation of pg_stat_activity query strings

Hi, I've recently seen a benchmark in which pg_mbcliplen() showed up prominently. Which it will basically in any benchmark with longer query strings, but fast queries. That's not that uncommon. I wonder if we could avoid the cost of pg_mbcliplen() from within pgstat_report_activity(), by moving s

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 7:31 AM, Amit Langote wrote: > On 2017/09/11 19:45, Ashutosh Bapat wrote: >> On Mon, Sep 11, 2017 at 12:16 PM, Amit Langote wrote: >>> IMHO, we should make it the responsibility of the future patch to set a >>> child PlanRowMark's prti to the direct parent's RT index, when

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/11 21:07, Ashutosh Bapat wrote: > On Mon, Sep 11, 2017 at 5:19 PM, Robert Haas wrote: >> On Mon, Sep 11, 2017 at 6:45 AM, Ashutosh Bapat >> wrote: >>> So, all partitioned partitions are getting locked correctly. Am I >>> missing something? >> >> That's not a valid test. In that scenar

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

> read side. I think that should work because all *server side* encodings > store character lengths in the *first* byte of a multibyte character What do you mean? I don't see such data in a multibyte string. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 1:16 PM, Amit Langote wrote: > On 2017/09/11 21:07, Ashutosh Bapat wrote: >> On Mon, Sep 11, 2017 at 5:19 PM, Robert Haas wrote: >>> On Mon, Sep 11, 2017 at 6:45 AM, Ashutosh Bapat >>> wrote: So, all partitioned partitions are getting locked correctly. Am I miss

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/12 16:55, Ashutosh Bapat wrote: > On Tue, Sep 12, 2017 at 1:16 PM, Amit Langote wrote: >> So I looked at this a bit closely and came to the conclusion that we may >> not need to keep partitioned table RT indexes in the >> (Merge)Append.partitioned_rels after all, as far as execution-time

Re: [HACKERS] postgres_fdw super user checks

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

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On 2017-09-12 16:53:49 +0900, Tatsuo Ishii wrote: > > read side. I think that should work because all *server side* encodings > > store character lengths in the *first* byte of a multibyte character > > What do you mean? I don't see such data in a multibyte string. Check the information the pg_*

Re: [HACKERS] Walsender timeouts and large transactions

Hello, At Wed, 06 Sep 2017 13:46:16 +, Yura Sokolov wrote in <20170906134616.18925.88390.p...@coridan.postgresql.org> > I've changed to "need review" to gain more attention from other. I understand that the problem here is too fast network prohibits walsender from sending replies. In physi

Re: [HACKERS] pg_basebackup behavior on non-existent slot

On Wed, Sep 6, 2017 at 11:50 AM, Alvaro Herrera wrote: > Magnus Hagander wrote: > > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote: > > > > Should the parent process of pg_basebackup be made to respond to > SIGCHLD? > > > Or call waitpid(bgchild, &status, WNOHANG) in some strategic loop? > > >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/12 16:39, Ashutosh Bapat wrote: > On Tue, Sep 12, 2017 at 7:31 AM, Amit Langote > wrote: >> On 2017/09/11 19:45, Ashutosh Bapat wrote: >>> On Mon, Sep 11, 2017 at 12:16 PM, Amit Langote wrote: IMHO, we should make it the responsibility of the future patch to set a child PlanRo

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 1:42 PM, Amit Langote wrote: > On 2017/09/12 16:55, Ashutosh Bapat wrote: >> On Tue, Sep 12, 2017 at 1:16 PM, Amit Langote wrote: >>> So I looked at this a bit closely and came to the conclusion that we may >>> not need to keep partitioned table RT indexes in the >>> (Merge

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

Thanks Ashutosh for taking a look at this. On 2017/09/05 21:16, Ashutosh Bapat wrote: > The patch needs a rebase. Attached rebased patch. Thanks, Amit From 75bcb6ebcc00193cb0251fced994f03d205e9e7f Mon Sep 17 00:00:00 2001 From: amit Date: Wed, 10 May 2017 10:37:42 +0900 Subject: [PATCH] Add som

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

> Check the information the pg_*_mblen use / how the relevant encodings > work. Will be something like > int > pg_utf_mblen(const unsigned char *s) > { > int len; > > if ((*s & 0x80) == 0) > len = 1; > else if ((*s & 0xe0) == 0xc0) >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/12 17:53, Ashutosh Bapat wrote: > On Tue, Sep 12, 2017 at 1:42 PM, Amit Langote wrote: >> So, we can remove partitioned_rels from (Merge)AppendPath and >> (Merge)Append nodes and remove ExecLockNonLeafAppendTables(). > > Don't we need partitioned_rels from Append paths to be transferred

[HACKERS] Optimise default partition scanning while adding new partition

Hi, Commit 6f6b99d1335be8ea1b74581fc489a97b109dd08a introduced default partitioning support. This commit added a new function check_default_allows_bound(), which checks if there exists a row in the default partition that would belong to the new partition being added. If it finds one, it throws an

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 2:17 PM, Amit Langote wrote: > > That said, I noticed that we might need to be careful about what the value > of the root parent's PlanRowMark's allMarkType field gets set to. We need > to make sure that it reflects markType of all partitions in the tree, > including those

Re: [HACKERS] Partition-wise aggregation/grouping

On Fri, Sep 8, 2017 at 5:47 PM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > Here are the new patch-set re-based on HEAD (f0a0c17) and > latest partition-wise join (v29) patches. > Hi Jeevan, I have started testing partition-wise-aggregate and got one observation, please take a look.

Re: [HACKERS] Automatic testing of patches in commit fest

Hi Tomas, > > I hope this observation will change your mind :) > > > > Not sure. But I'm mostly just a passenger here, not the driver. After working on this script for some time I got second thoughts regarding this idea as well. The reason for this is that the script is just a bunch of regular

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/12 18:49, Ashutosh Bapat wrote: > On Tue, Sep 12, 2017 at 2:17 PM, Amit Langote > wrote: >> >> That said, I noticed that we might need to be careful about what the value >> of the root parent's PlanRowMark's allMarkType field gets set to. We need >> to make sure that it reflects markTy

Re: [HACKERS] Supporting huge pages on Windows

On Thu, Aug 17, 2017 at 2:11 PM, Thomas Munro wrote: > On Wed, Apr 12, 2017 at 7:08 PM, Tsunakawa, Takayuki > wrote: >> Oh, I got it now. Thanks. The revised patch is attached. The only >> modified file is pg_ctl.c. The patch worked as expected. >> >> It is regrettable that I could not make

Re: [HACKERS] Setting pd_lower in GIN metapage

On 2017/09/11 18:13, Michael Paquier wrote: > On Mon, Sep 11, 2017 at 5:40 PM, Amit Langote wrote: >> On 2017/09/10 15:22, Michael Paquier wrote: >>> Coordinating efforts here would be nice. If you, Amit K, are taking >>> care of a patch for btree and hash, would you, Amit L, write the part >>> for

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 2:35 PM, Amit Langote wrote: > On 2017/09/12 17:53, Ashutosh Bapat wrote: >> On Tue, Sep 12, 2017 at 1:42 PM, Amit Langote wrote: >>> So, we can remove partitioned_rels from (Merge)AppendPath and >>> (Merge)Append nodes and remove ExecLockNonLeafAppendTables(). >> >> Don't

Re: [HACKERS] Automatic testing of patches in commit fest

On Tue, Sep 12, 2017 at 10:03 PM, Aleksander Alekseev wrote: > Unless there are any objections I'm going to give these patches "Waiting > on Author" status today (before doing this I'll re-run the script to > make sure that the list is up-to-date). I'm also going to write one more > email with CC

Re: [HACKERS] Constraint exclusion for partitioned tables

Hi, I had a look at these changes and here are my observations: 1. Patch applies cleanly with "git apply'. 2. make / make install / make check-world all are good. This patch clearly improves the planning time with given conditions. To verify that, I have created a table like: create table foo(a

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

On Tue, Sep 12, 2017 at 2:27 PM, Amit Langote wrote: > Thanks Ashutosh for taking a look at this. > > On 2017/09/05 21:16, Ashutosh Bapat wrote: >> The patch needs a rebase. > > Attached rebased patch. Thanks for rebased patch. We could annotate each ERROR with an explanation as to why that's an

Re: [HACKERS] Log LDAP "diagnostic messages"?

The patch needs to address some comments in the previous mails, so marking it as "waiting for author". On Wed, Aug 16, 2017 at 11:13 AM, Ashutosh Bapat wrote: > On Wed, Aug 16, 2017 at 8:44 AM, Alvaro Herrera > wrote: >> Christoph Berg wrote: >>> Re: Thomas Munro 2017-08-10 >>> >>> > > Agreed.

Re: [HACKERS] [PATCH] Improve geometric types

Hello, sorry to late for the party, but may I comment on this? At Tue, 05 Sep 2017 13:18:12 +, Aleksander Alekseev wrote in <20170905131812.18925.13551.p...@coridan.postgresql.org> > The following review has been posted through the commitfest application: > make installcheck-world: tested,

Re: [HACKERS] why not parallel seq scan for slow functions

On 5 September 2017 at 14:04, Amit Kapila wrote: > On Fri, Aug 25, 2017 at 10:08 PM, Robert Haas wrote: >> On Mon, Aug 21, 2017 at 5:08 AM, Amit Kapila wrote: >>> (b) I have changed the costing of gather path for path target in >>> generate_gather_paths which I am not sure is the best way. Anoth

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

On 9/11/17 18:21, Michael Paquier wrote: > On Tue, Sep 12, 2017 at 5:57 AM, Peter Eisentraut > wrote: >> I have committed this patch, after a perltidy run, but the way the libz >> detection was implemented was a bit too hackish for me, so I have >> omitted that for now. > > Thanks. > >> I think

Re: [HACKERS] CLUSTER command progress monitor

On 2017/09/11 23:38, Robert Haas wrote: On Sun, Sep 10, 2017 at 10:36 PM, Tatsuro Yamada wrote: Thanks for the comment. As you know, CLUSTER command uses SEQ SCAN or INDEX SCAN as a scan method by cost estimation. In the case of SEQ SCAN, these two phases not overlap. However, in INDEX SCAN, i

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

On Tue, Sep 12, 2017 at 9:19 PM, Peter Eisentraut wrote: > On 9/11/17 18:21, Michael Paquier wrote: >> On Tue, Sep 12, 2017 at 5:57 AM, Peter Eisentraut >> wrote: >>> I think a more robust way would be to parse >>> Makefile.global, perhaps by a function in TestLib, so it can be reused >>> in othe

Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)

Jim Nasby writes: > I've verified that the patch still applies and make check-world is clean. Not any more :-(. Here's a v3 rebased over HEAD. No substantive change from v2. regards, tom lane diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c inde

Re: [HACKERS] Partition-wise aggregation/grouping

On Tue, Sep 12, 2017 at 3:24 PM, Rajkumar Raghuwanshi < rajkumar.raghuwan...@enterprisedb.com> wrote: > > On Fri, Sep 8, 2017 at 5:47 PM, Jeevan Chalke com> wrote: > >> Here are the new patch-set re-based on HEAD (f0a0c17) and >> latest partition-wise join (v29) patches. >> > > Hi Jeevan, > > I h

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

On 9/11/17 03:11, Michael Banck wrote: >> Is there a race condition here? The slot is created after the checkpoint >> is completed. But you have to start streaming from the LSN where the >> checkpoint started, so shouldn't the slot be created before the checkpoint >> is started? > > So my patch

Re: [HACKERS] CLUSTER command progress monitor

On 2017/09/12 21:20, Tatsuro Yamada wrote: On 2017/09/11 23:38, Robert Haas wrote: On Sun, Sep 10, 2017 at 10:36 PM, Tatsuro Yamada wrote: Thanks for the comment. As you know, CLUSTER command uses SEQ SCAN or INDEX SCAN as a scan method by cost estimation. In the case of SEQ SCAN, these two p

Re: [HACKERS] PG 10 release notes

On 09/12/2017 01:50 AM, Bruce Momjian wrote: > I don't know, but I suggest you read this email thread from April to get > an idea of how performance items are handled: > > > https://www.postgresql.org/message-id/flat/20170425013144.GA7513%40momjian.us#20170425013144.ga7...@momjian.us Oh, s

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

I wrote: > Looking at the patch, it still seems solid, but I remember that one > thing I was concerned about was whether the more generalized code > was any slower. Not sure about a good test case to measure that > though --- const-simplification isn't a large chunk of most workloads. This patch

Re: [HACKERS] More flexible LDAP auth search filters?

On 9/11/17 23:58, Thomas Munro wrote: > Sounds good. Here it is with $username. It's nice not to have to > escape any characters in URLs. I suppose more keywords could be added > in follow-up patches if someone thinks that would be useful > ($hostname, $dbname, ...?). I got sick of that buffer

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Robert Haas wrote: > I just don't understand why you think there should be multiple > spellings of the same bound. Generally, canonicalization is good. > One of my fears here is that at least some people will get confused > and think a bound from (minvalue, 0) to (maxvalue, 10) allows any > value

Re: [HACKERS] Automatic testing of patches in commit fest

Aleksander Alekseev writes: > I've ended up with this script [1]. It just generates a list of patches > that are in "Needs Review" status but don't apply or don't compile. Here > is the current list: > === Apply Failed: 29 === > https://commitfest.postgresql.org/14/1235/ (Support arrays over doma

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

Hello, hackers! Thanks to the work of Thomas Munro now we have a CI for the patches on the commitfest [1]. Naturally there is still room for improvement, but in any case it's much, much better than nothing. After a short discussion [2] we agreed (or at least no one objected) to determine the patc

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> I just don't understand why you think there should be multiple >> spellings of the same bound. Generally, canonicalization is good. >> One of my fears here is that at least some people will get confused >> and think a

Re: [HACKERS] Setting pd_lower in GIN metapage

On Tue, Sep 12, 2017 at 3:51 PM, Amit Langote wrote: > On 2017/09/11 18:13, Michael Paquier wrote: >> On Mon, Sep 11, 2017 at 5:40 PM, Amit Langote wrote: >>> On 2017/09/10 15:22, Michael Paquier wrote: Coordinating efforts here would be nice. If you, Amit K, are taking care of a patch f

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On 30 March 2017 at 13:11, Peter Moser wrote: > 2017-03-01 10:56 GMT+01:00 Peter Moser : >> A similar walkthrough for ALIGN will follow soon. >> >> We are thankful for any suggestion or ideas, to be used to write a >> good SGML documentation. > > The attached README explains the ALIGN operation st

Re: [HACKERS] Automatic testing of patches in commit fest

Tom Lane wrote: > Aleksander Alekseev writes: > > I've ended up with this script [1]. It just generates a list of patches > > that are in "Needs Review" status but don't apply or don't compile. Here > > is the current list: > > > === Apply Failed: 29 === > > https://commitfest.postgresql.org/14/1

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

On Mon, Sep 11, 2017 at 6:41 PM, Michael Paquier wrote: > On Mon, Sep 11, 2017 at 11:43 PM, Robert Haas wrote: >> So I think this is just an excuse for turning --no-security-labels >> into --no-object-property=security-label. To me, that's just plain >> worse. > > It does not seem that my though

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 9/10/17 22:37, Michael Paquier wrote: > On Mon, Aug 21, 2017 at 9:51 PM, Michael Paquier > wrote: >> On Tue, Jun 20, 2017 at 1:11 PM, Michael Paquier >> wrote: >>> With the tests directly in the patch, things are easy to run. WIth >>> PG10 stabilization work, of course I don't expect much feed

Re: [HACKERS] Constraint exclusion for partitioned tables

On Tue, Sep 12, 2017 at 7:08 AM, Jeevan Chalke wrote: > This patch clearly improves the planning time with given conditions. > > To verify that, I have created a table like: > create table foo(a int, b int check (b > 100), c text) partition by > range(a); > And then used following query to get pla

[HACKERS] pg_rewind proposed scope and interface changes

Hi all; After working with pg_rewind a bit more it has become clear to me that some aspects of the ideal scope of the program are a bit unclear. This is in part because the majority of cases where you use the utility, a small amount of data loss is accepted due to the tradeoff of continuity. B

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

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

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

Here's an updated version of this patch that is rebased against HEAD (no changes there except line numbers) and adds the necessary updates for contrib. I'd like to get this committed fairly soon before it bit-rots. Anyone want to review it? regards, tom lane diff --git a/

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

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

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On Mon, 24 Jul 2017 11:59:13 +0900 Etsuro Fujita wrote: > On 2017/07/21 19:16, Etsuro Fujita wrote: > > On 2017/07/20 11:21, Etsuro Fujita wrote: > >> On 2017/07/19 23:36, Tom Lane wrote: > >>> Please put the responsibility of doing const-expression > >>> simplification in these cases somewhe

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

On Tue, Sep 12, 2017 at 3:19 AM, Andres Freund wrote: > Therefore I wonder if we couldn't just store a querystring that's > essentially just a memcpy()ed prefix, and do a pg_mbcliplen() on the > read side. I think that should work because all *server side* encodings > store character lengths in t

Re: [HACKERS] Automatic testing of patches in commit fest

Alvaro Herrera writes: > Tom Lane wrote: >> Aleksander Alekseev writes: >>> === Apply Failed: 29 === >>> https://commitfest.postgresql.org/14/1235/ (Support arrays over domain >>> types) >> Can you clarify what went wrong for you on that one? I went to rebase it, >> but I end up with the ident

Re: [HACKERS] DROP SUBSCRIPTION hangs if sub is disabled in the same transaction

On Wed, Sep 6, 2017 at 3:28 PM, Masahiko Sawada wrote: > On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher wrote: >> Arseny Sher writes: >> >>> Attached patch fixes this by stopping workers before RO drop, as >>> already done in case when we drop replication slot. >> >> Sorry, here is the patch. >> >

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

Robert Haas writes: > On Tue, Sep 12, 2017 at 3:19 AM, Andres Freund wrote: >> Therefore I wonder if we couldn't just store a querystring that's >> essentially just a memcpy()ed prefix, and do a pg_mbcliplen() on the >> read side. > Interesting idea. I was (ha, ha, what a coincidence) also thin

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Robert Haas writes: > On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera > wrote: >> Did anything happen on this, or did we just forget it completely? > I forgot it. :-( > I really think we should fix this. +1. You've got the rest of the week ... regards, tom lane --

Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

On Wednesday, May 24, 2017 9:38:36 PM EDT Tsunakawa, Takayuki wrote: > The clients will know the change of session_read_only when they do > something that calls RecoveryInProgress(). Currently, > RecoveryInProgress() seems to be the only place where the sessions > notice the promotion, so I set se

Re: [HACKERS] Small improvement to compactify_tuples

On 2017-07-21 13:49, Sokolov Yura wrote: On 2017-05-17 17:46, Sokolov Yura wrote: Alvaro Herrera писал 2017-05-15 20:13: As I understand, these patches are logically separate, so putting them together in a single file isn't such a great idea. If you don't edit the patches further, then you're

Re: [HACKERS] Automatic testing of patches in commit fest

Hi, On 2017-09-12 11:30:33 -0400, Tom Lane wrote: > One thing I'm a tad worried about is automatically running trojan-horsed > submissions. I hope the CI bot is tightly sandboxed. Well, that's part of the nice thing here. The "really dangerous stuff" is all running on a service that does so full

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Also I didn't manage to find any typos or obvious mistakes in

Re: [HACKERS] DROP SUBSCRIPTION hangs if sub is disabled in the same transaction

Masahiko Sawada writes: > FWIW, perhaps we can change the replication origin management so that > DROP SUBSCRIPTION doesn't drop the replication origin and the apply > worker itself removes it when exit. When an apply worker exits it > removes the replication origin if the corresponding subscript

[HACKERS] pgbench regression test failure

francolin just showed a non-reproducing failure in the new pgbench tests: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=francolin&dt=2017-09-12%2014%3A00%3A02 The relevant part of the log is # Running: pgbench -T 2 -P 1 -l --log-prefix=001_pgbench_log_1 --aggregate-interval=1 -S -b se@

Re: [HACKERS] MAIN, Uncompressed?

On 29 August 2017 at 07:58, Simon Riggs wrote: > On 26 August 2017 at 05:40, Mark Kirkwood > wrote: >> On 26/08/17 12:18, Simon Riggs wrote: >> >>> On 25 August 2017 at 20:53, Tom Lane wrote: Greg Stark writes: > > I think this is a particularly old piece of code and we're lu

Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and > from >=

Aleksander Alekseev writes: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:tested, passed > Also I didn't manage

Re: [HACKERS] Surjective functional indexes

On 1 September 2017 at 09:47, Konstantin Knizhnik wrote: > > On 01.09.2017 09:25, Simon Riggs wrote: >> >> On 1 September 2017 at 05:40, Thomas Munro >> wrote: >>> >>> On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik >>> wrote: Attached please find rebased version of the patch.

Re: [HACKERS] Automatic testing of patches in commit fest

On Tue, Sep 12, 2017 at 8:30 AM, Tom Lane wrote: > +1 ... seems like there's enough noise here that changing patch status > based on the results might be premature. Still, I applaud the effort. There are always going to be cases where the tool fails, unless there are more formal guidelines on pa

Re: [HACKERS] [PATCH] Add citext_pattern_ops to citext contrib module

Alexey Chernyshov writes: > The attached patch introduces citext_pattern_ops for citext extension > type like text_pattern_ops for text type. Here are operators ~<~, ~<=~, > ~>~, ~>=~ combined into citext_pattern_ops operator class. These > operators simply compare underlying citext values as C

Re: [HACKERS] pgbench regression test failure

francolin just showed a non-reproducing failure in the new pgbench tests: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=francolin&dt=2017-09-12%2014%3A00%3A02 not ok 211 - transaction count for 001_pgbench_log_1.31583 (3) # Failed test 'transaction count for 001_pgbench_log_1.3

Re: [HACKERS] Cached plans and statement generalization

On 11.09.2017 12:24, Konstantin Knizhnik wrote: Attached please find rebased version of the patch. There are the updated performance results (pgbench -s 100 -c 1): protocol (-M) read-write read-only (-S) simple 3327 19325 extended 2256 16908 prep

Re: [HACKERS] pgbench regression test failure

Fabien COELHO writes: >> Apparently, one of the threads ran 3 transactions where the test script >> expects it to run at most 2. Is this a pgbench bug, or is the test >> being overoptimistic about how exact the "-T 2" cutoff is? > Probably both? It seems that cutting off on time is not a precise

[HACKERS] domain type smashing is expensive

On short-running queries that return a lot of columns, SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a noticeable expense. The following change improves performance on a query returning 100 columns by about 6% when prepared queries are in use (Mithun Cy and I both tested and got

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

On Thu, Aug 3, 2017 at 11:37:32AM +0200, Michael Paquier wrote: > On Mon, Jul 31, 2017 at 6:13 PM, Robert Haas wrote: > > On Fri, Jul 28, 2017 at 10:35 AM, Andreas Joseph Krogh > > wrote: > >> I'm reading https://www.postgresql.org/docs/10/static/pgupgrade.html to try > >> to understand how to u

Re: [HACKERS] psql - add special variable to reflect the last query status

Hello Tom, Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that situation where libpq did not report an error? Meh. If we're going to do that I think it might be better to hack libpq itself to do so, ie, force PQresultErrorField(..., PG_DIAG_SQLSTATE) to always return som

Re: [HACKERS] [PATCH] Improve geometric types

> Hello, sorry to late for the party, but may I comment on this? Thank you for picking this up again. > The first patch reconstructs the operators in layers. These > functions are called very frequently when used. Some function are > already inlined in float.h but some static functions in float.h

Re: [HACKERS] pg_basebackup behavior on non-existent slot

On Wed, Sep 6, 2017 at 2:50 AM, Alvaro Herrera wrote: > Magnus Hagander wrote: > > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote: > > > > Should the parent process of pg_basebackup be made to respond to > SIGCHLD? > > > Or call waitpid(bgchild, &status, WNOHANG) in some strategic loop? > > >

Re: [HACKERS] domain type smashing is expensive

Robert Haas writes: > On short-running queries that return a lot of columns, > SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a > noticeable expense. Yeah, I was never very happy with the way that the original domain patch dealt with that. I think you're not even focusing on the

Re: [HACKERS] Surjective functional indexes

On 12.09.2017 19:28, Simon Riggs wrote: On 1 September 2017 at 09:47, Konstantin Knizhnik wrote: On 01.09.2017 09:25, Simon Riggs wrote: On 1 September 2017 at 05:40, Thomas Munro wrote: On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik wrote: Attached please find rebased version of th

[HACKERS] [PATCH] Call RelationDropStorage() for broader range of object drops.

Motivation for this patch is that some FDWs (notably, cstore_fdw) try utilizing PostgreSQL internal storage. PostgreSQL assigns relfilenode's to foreign tables, but doesn't clean up storage for foreign tables when dropping tables. Therefore, in cstore_fdw we have to do some tricks to handle droppin

Re: [HACKERS] pgbench regression test failure

Apparently, one of the threads ran 3 transactions where the test script expects it to run at most 2. Is this a pgbench bug, or is the test being overoptimistic about how exact the "-T 2" cutoff is? Probably both? It seems that cutting off on time is not a precise science, so I suggest to acc

Re: [HACKERS] pgbench regression test failure

Fabien COELHO writes: > By definition, parallelism induces non determinism. When I put 2 seconds, > the intention was that I would get a non empty trace with a "every second" > aggregation. I would rather take a longer test rather than allowing an > empty file: the point is to check that someth

Re: [HACKERS] domain type smashing is expensive

On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane wrote: > Robert Haas writes: >> On short-running queries that return a lot of columns, >> SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a >> noticeable expense. > > Yeah, I was never very happy with the way that the original domain > pat

Re: [HACKERS] psql - add special variable to reflect the last query status

On Tue, Sep 12, 2017 at 1:23 PM, Fabien COELHO wrote: > I added two error codes, which is debatable. One is used hardcoded by libpq > if no diagnostic is found, and the other by psql if libpq returned something > empty, which might happen if psql is linked with an older libpq, maybe. I do > not kn

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-12 20:43 GMT+02:00 Robert Haas : > On Tue, Sep 12, 2017 at 1:23 PM, Fabien COELHO > wrote: > > I added two error codes, which is debatable. One is used hardcoded by > libpq > > if no diagnostic is found, and the other by psql if libpq returned > something > > empty, which might happen if

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På tirsdag 12. september 2017 kl. 19:19:22, skrev Bruce Momjian < br...@momjian.us >: On Thu, Aug  3, 2017 at 11:37:32AM +0200, Michael Paquier wrote: > On Mon, Jul 31, 2017 at 6:13 PM, Robert Haas wrote: > > On Fri, Jul 28, 2017 at 10:35 AM, Andreas Joseph Krogh > > w

Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list

Hi I am sending rebased patch Regards Pavel diff --git a/src/pl/plpgsql/src/pl_gram.y b/src/pl/plpgsql/src/pl_gram.y index 94f1f58593..4b6bf0b5bc 100644 --- a/src/pl/plpgsql/src/pl_gram.y +++ b/src/pl/plpgsql/src/pl_gram.y @@ -92,9 +92,10 @@ static char *NameOfDatum(PLwdatum *wdatum); static

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 12, 2017 at 3:46 AM, Amit Langote wrote: > In this case, AcquireExecutorLocks will lock all the relations in > PlannedStmt.rtable, which must include all partitioned tables of all > partition trees involved in the query. Of those, it will lock the tables > whose RT indexes appear in P

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

On Tue, Sep 12, 2017 at 2:59 PM, Andreas Joseph Krogh wrote: > There are many ways to do/configure things it seems, resulting in many ifs > and buts which makes section 10 rather confusing. I really think a complete > example, with absolute paths, would be clarifying. > > I'm afraid many will stil

Re: [HACKERS] psql - add special variable to reflect the last query status

Robert Haas writes: > On Tue, Sep 12, 2017 at 1:23 PM, Fabien COELHO wrote: >> I added two error codes, which is debatable. One is used hardcoded by libpq >> if no diagnostic is found, and the other by psql if libpq returned something >> empty, which might happen if psql is linked with an older l

Re: [HACKERS] psql - add special variable to reflect the last query status

On Tue, Sep 12, 2017 at 3:12 PM, Tom Lane wrote: >> I think this is a bad plan. Right now, libpq sets no SQLSTATE for >> internally generated errors; it is almost certain that there are >> applications testing for an empty SQLSTATE to notice when they're >> getting an error from libpq. Enterpris

Re: [HACKERS] domain type smashing is expensive

Robert Haas writes: > On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane wrote: >> The trick here is that I don't think we want to change the returned column >> types for queries that are not being sent to a client. The parser and >> planner aren't really aware of that context ATM. Maybe we could make t

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På tirsdag 12. september 2017 kl. 21:11:45, skrev Robert Haas < robertmh...@gmail.com >: On Tue, Sep 12, 2017 at 2:59 PM, Andreas Joseph Krogh wrote: > There are many ways to do/configure things it seems, resulting in many ifs > and buts which makes section 10 rath

Re: [HACKERS] pgbench regression test failure

I have a serious, serious dislike for tests that seem to work until they're run on a heavily loaded machine. I'm not that sure the error message was because of that. ISTM that it was rather finding 3 seconds in two because it started just at the right time, or maybe because of slowness induc

Re: [HACKERS] psql - add special variable to reflect the last query status

Robert Haas writes: > Well, if we provided a different SQLSTATE for each qualitatively > different type of libpq error, that might well be useful enough to > justify some risk of application breakage. But replacing a constant > string that we've had for ~15 years with a different constraint strin

Re: [HACKERS] pgbench regression test failure

Fabien COELHO writes: >> I have a serious, serious dislike for tests that seem to work until >> they're run on a heavily loaded machine. > I'm not that sure the error message was because of that. No, this particular failure (probably) wasn't. But now that I've realized that this test case is ti

Re: [HACKERS] Automatic testing of patches in commit fest

On 09/12/2017 11:30 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Aleksander Alekseev writes: === Apply Failed: 29 === https://commitfest.postgresql.org/14/1235/ (Support arrays over domain types) >>> Can you clarify what went wrong for you on that one? I

Re: [HACKERS] psql - add special variable to reflect the last query status

Well, if we provided a different SQLSTATE for each qualitatively different type of libpq error, that might well be useful enough to justify some risk of application breakage. But replacing a constant string that we've had for ~15 years with a different constraint string isn't doing anything abo

  1   2   >