Re: Failed to delete old ReorderBuffer spilled files

On Wed, Nov 22, 2017 at 2:56 PM, Craig Ringer wrote: > On 22 November 2017 at 12:15, Kyotaro HORIGUCHI > wrote: >> >> At Wed, 22 Nov 2017 12:57:34 +0900, Michael Paquier >> wrote in >>

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

Note that the patch may interact with other patches which add functions to pgbench, so might need a rebase depending on the order in which the patch are applied. Attached a minor rebase after 16827d4424. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml

Re: With commit 4e5fe9ad19, range partition missing handling for the NULL partition key

Hi Rushabh, On 2017/11/22 13:45, Rushabh Lathia wrote: > Consider the below test: > > CREATE TABLE range_tab(a int, b int) PARTITION BY RANGE(a); > CREATE TABLE range_tab_p1 PARTITION OF range_tab FOR VALUES FROM (minvalue) > TO (10); > CREATE TABLE range_tab_p2 PARTITION OF range_tab FOR VALUES

Re: Failed to delete old ReorderBuffer spilled files

On 22 November 2017 at 12:15, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > At Wed, 22 Nov 2017 12:57:34 +0900, Michael Paquier < > michael.paqu...@gmail.com> wrote in

Re: [HACKERS] Issues with logical replication

On 4 October 2017 at 10:35, Petr Jelinek wrote: > On 02/10/17 18:59, Petr Jelinek wrote: >>> >>> Now fix the trigger function: >>> CREATE OR REPLACE FUNCTION replication_trigger_proc() RETURNS TRIGGER AS $$ >>> BEGIN >>> RETURN NEW; >>> END $$ LANGUAGE plpgsql; >>>

With commit 4e5fe9ad19, range partition missing handling for the NULL partition key

Consider the below test: CREATE TABLE range_tab(a int, b int) PARTITION BY RANGE(a); CREATE TABLE range_tab_p1 PARTITION OF range_tab FOR VALUES FROM (minvalue) TO (10); CREATE TABLE range_tab_p2 PARTITION OF range_tab FOR VALUES FROM (10) TO (20); CREATE TABLE range_tab_p3 PARTITION OF range_tab

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Hi Nathan, Thanks for review comments. Enclosed please find the patch which has been updated according to your suggestion. The CURRENT_DATABASE can be used as following SQL statements and people can find information from sgml files: 1. COMMENT ON DATABASE CURRENT_DATABASE is ... 2.

Re: [HACKERS] Issues with logical replication

On 4 October 2017 at 07:35, Petr Jelinek wrote: > On 02/10/17 18:59, Petr Jelinek wrote: > >> > >> Now fix the trigger function: > >> CREATE OR REPLACE FUNCTION replication_trigger_proc() RETURNS TRIGGER > AS $$ > >> BEGIN > >> RETURN NEW; > >> END $$ LANGUAGE

Re: Failed to delete old ReorderBuffer spilled files

At Wed, 22 Nov 2017 12:57:34 +0900, Michael Paquier wrote in

Re: [HACKERS] More stats about skipped vacuums

On Wed, Nov 22, 2017 at 1:08 PM, Kyotaro HORIGUCHI wrote: > At Wed, 22 Nov 2017 08:20:22 +0900, Michael Paquier > wrote in > >> On Tue, Nov 21, 2017 at 4:09 PM,

Re: [HACKERS] More stats about skipped vacuums

Hello, At Wed, 22 Nov 2017 08:20:22 +0900, Michael Paquier wrote in > On Tue, Nov 21, 2017 at 4:09 PM, Kyotaro HORIGUCHI > wrote: > > By the way I'm uneasy that the

Re: Logical Replication and triggers

On 22 November 2017 at 05:35, Robert Haas wrote: > On Tue, Nov 21, 2017 at 4:28 PM, Simon Riggs > wrote: > > I would have acted on this myself a few days back if I thought the > > patch was correct, but I see multiple command counter increments > >

Re: Logical Replication and triggers

On 22 November 2017 at 02:27, Robert Haas wrote: > On Sat, Nov 18, 2017 at 7:30 PM, Craig Ringer > wrote: > > On 15 November 2017 at 21:12, Thomas Rosenstein > > wrote: > >> I would like somebody to consider Petr

Re: Failed to delete old ReorderBuffer spilled files

At Tue, 21 Nov 2017 20:53:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171121.205304.90315453.horiguchi.kyot...@lab.ntt.co.jp> > At Tue, 21 Nov 2017 20:27:25 +0900, atorikoshi > wrote in >

Re: Logical Replication and triggers

On Tue, Nov 21, 2017 at 4:28 PM, Simon Riggs wrote: > I would have acted on this myself a few days back if I thought the > patch was correct, but I see multiple command counter increments > there, so suspect an alternate fix is correct. Oh, well, I'm glad you said

Re: default range partition and constraint exclusion

On Tue, Nov 21, 2017 at 4:36 AM, Amit Langote wrote: >>> The attached will make the constraint to look like: >> >> Uh, if the constraint exclusion logic we're using is drawing false >> conclusions, we need to fix it so it doesn't, not change the >> constraint so

Re: Logical Replication and triggers

On 21 November 2017 at 16:13, Thomas Rosenstein wrote: > To weigh in here, I actually find it's a big hurdle > > I'm a postgres user and not a postgres dev, so I definitly have the feeling > I'm not qualified to answer if this really does what it's intended

Re: [HACKERS] CLUSTER command progress monitor

On Tue, Nov 21, 2017 at 12:55 PM, Robert Haas wrote: > I agree. > > I have been of the opinion all along that progress monitoring needs to > report facts, not theories. The number of tuples read thus far is a > fact, and is fine to report for whatever value it may have to

Re: Logical Replication and triggers

On Tue, Nov 21, 2017 at 3:29 PM, Simon Riggs wrote: You realize we're talking about a bug fix, right? And for a feature that was developed and committed by your colleagues? Craig is asking Thomas to confirm the proposed bug fix works. How is this not normal? That's

Re: [HACKERS] CLUSTER command progress monitor

On Mon, Oct 2, 2017 at 6:04 AM, Robert Haas wrote: > Progress reporting on sorts seems like a tricky problem to me, as I > said before. In most cases, a sort is going to involve an initial > stage where it reads all the input tuples and writes out quicksorted > runs, and

Re: [HACKERS] Replication status in logical replication

On Tue, Nov 14, 2017 at 6:46 AM, Thomas Munro wrote: > On Tue, Sep 26, 2017 at 3:45 PM, Masahiko Sawada > wrote: >> On Tue, Sep 26, 2017 at 10:36 AM, Vaishnavi Prabakaran >> wrote: >>> On Wed, Sep 13, 2017 at

Re: feature request: consume asynchronous notification via a function

On Tue, Nov 21, 2017 at 2:16 PM, Merlin Moncure wrote: > On Tue, Nov 21, 2017 at 12:20 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Tue, Nov 21, 2017 at 11:32 AM, Merlin Moncure wrote: I am very much

Re: [HACKERS] [PATCH] Incremental sort

On Tue, Nov 21, 2017 at 1:00 PM, Alexander Korotkov wrote: > On Mon, Nov 20, 2017 at 12:24 AM, Thomas Munro > wrote: >> Is there some reason not to use ApplySortComparator for this? I think >> you're missing out on lower-overhead

Re: [HACKERS] CLUSTER command progress monitor

On Mon, Nov 20, 2017 at 12:05 PM, Antonin Houska wrote: > Robert Haas wrote: >> On Wed, Aug 30, 2017 at 10:12 PM, Tatsuro Yamada >> wrote: >> > 1. scanning heap >> > 2. sort tuples >> >> These two phases overlap, though.

Re: [HACKERS] CLUSTER command progress monitor

On Mon, Nov 20, 2017 at 12:25 PM, Tom Lane wrote: > Antonin Houska writes: >> Robert Haas wrote: >>> These two phases overlap, though. I believe progress reporting for >>> sorts is really hard. > >> Whatever complexity is hidden in

Re: Combine function returning NULL unhandled?

On Mon, Nov 20, 2017 at 10:36 PM, Andres Freund wrote: > The plain transition case contains: > if (pergroupstate->transValueIsNull) > { > /* > * Don't call a strict function with NULL inputs. >

Re: [HACKERS] Custom compression methods

On 11/21/2017 09:28 PM, Ildus K wrote: >> Hmmm, it still doesn't work for me. See this: >> >> test=# create extension pg_lz4 ; >> CREATE EXTENSION >> test=# create table t_lz4 (v text compressed lz4); >> CREATE TABLE >> test=# create table t_pglz (v text); >> CREATE TABLE

Re: [HACKERS] pgbench regression test failure

On Tue, Nov 21, 2017 at 3:28 PM, Tom Lane wrote: > Seems like a good idea, but the way you've written it is inconsistent > with the "n/m" notation used just above. I'd suggest > > ... latency limit: 33 (33/33, 100.000 %) > > or just > > ... latency limit: 33/33 (100.000 %)

Re: Logical Replication and triggers

On Tue, Nov 21, 2017 at 3:29 PM, Simon Riggs wrote: >> You realize we're talking about a bug fix, right? And for a feature >> that was developed and committed by your colleagues? > > Craig is asking Thomas to confirm the proposed bug fix works. How is > this not normal?

Re: Logical Replication and triggers

On 21 November 2017 at 13:27, Robert Haas wrote: > On Sat, Nov 18, 2017 at 7:30 PM, Craig Ringer wrote: >> On 15 November 2017 at 21:12, Thomas Rosenstein >> wrote: >>> I would like somebody to consider Petr

Re: [HACKERS] Custom compression methods

On Tue, 21 Nov 2017 18:47:49 +0100 Tomas Vondra wrote: > > I propose to use either > >CompressionMethodOptions (and CompressionMethodRoutine) > > or > >CompressionOptions (and CompressionRoutine) Sounds good, thanks. > > OK. But then I don't

Re: [HACKERS] pgbench regression test failure

Robert Haas writes: > On Mon, Nov 20, 2017 at 1:40 PM, Tom Lane wrote: >> I dunno, it just looks odd to me that when we've set up a test case in >> which every one of the transactions is guaranteed to exceed the latency >> limit, that it doesn't say

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

On Mon, Nov 20, 2017 at 5:19 PM, Masahiko Sawada wrote: > Attached updated version patch. I've moved only relation extension > locks out of heavy-weight lock as per discussion so far. > > I've done a write-heavy benchmark on my laptop; loading 24kB data to > one table using

Re: feature request: consume asynchronous notification via a function

On Tue, Nov 21, 2017 at 12:20 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Nov 21, 2017 at 11:32 AM, Merlin Moncure wrote: >>> I am very much looking at the new stored procedure functionality and >>> imaging a loop like

Re: [HACKERS] Parallel Append implementation

On Tue, Nov 21, 2017 at 6:57 AM, amul sul wrote: > By doing following change on the v19 patch does the fix for me: > > --- a/src/backend/executor/nodeAppend.c > +++ b/src/backend/executor/nodeAppend.c > @@ -489,11 +489,9 @@ choose_next_subplan_for_worker(AppendState *node) >

Re: [HACKERS] Re: protocol version negotiation (Re: Libpq PGRES_COPY_BOTH - version compatibility)

On Sun, Nov 19, 2017 at 7:49 PM, Badrul Chowdhury wrote: >>> I spent a little more time looking at this patch today. I think that the >>> patch >>> should actually send NegotiateProtocolVersion when *either* the requested >>> version is differs from the latest one we

Re: [HACKERS] SQL procedures

On 11/20/2017 04:25 PM, I wrote: > I've been through this fairly closely, and I think it's pretty much > committable. The only big item that stands out for me is the issue of > OUT parameters. > > While returning multiple result sets will be a useful feature, it's also > very common in my

Re: Does XMLSERIALIZE output xmlattributes in a stable order?

On 11/21/2017 11:49 AM, Tom Lane wrote: > AFAICS, XMLSERIALIZE in our current implementation boils down to > being a binary-compatible coercion from XML (which is stored as > a string) to text. So the interesting question here is where are > you getting the XML values from? The stability of the

Re: feature request: consume asynchronous notification via a function

Robert Haas writes: > On Tue, Nov 21, 2017 at 11:32 AM, Merlin Moncure wrote: >> I am very much looking at the new stored procedure functionality and >> imaging a loop like this: >> >> LOOP >> FOR r IN SELECT * FROM pg_get_notifications(30) >> LOOP

Re: View with duplicate GROUP BY entries

Robert Haas writes: > On Tue, Nov 21, 2017 at 12:05 PM, Tom Lane wrote: >> Yeah, we probably ought to make more of an effort to regenerate the >> original query wording. I do not think that forcing positional notation >> is a suitable answer in this

Re: feature request: consume asynchronous notification via a function

On Tue, Nov 21, 2017 at 11:32 AM, Merlin Moncure wrote: >> I think that wouldn't work very well, because I think we must have a >> snapshot open in order to run pg_get_notifications(), and that means >> we're holding back the system-wide xmin. > > I am very much looking at the

Re: View with duplicate GROUP BY entries

On Tue, Nov 21, 2017 at 12:05 PM, Tom Lane wrote: > Ashutosh Bapat writes: >> While reviewing patch for similar problem in postgres_fdw [1], I >> noticed that we don't use positional notation while creating the view. >> This might introduced

Re: to_typemod(type_name) information function

Greeting, Sophie! * Sophie Herold (sophi...@hemio.de) wrote: > I did not find any advice on how to choose a new OID for pg_proc. (Haven't looked at the patch itself yet really, but wanted to answer this.) The main thing is to not duplicate the OID, which you can avoid by calling 'unused_oids'

Re: View with duplicate GROUP BY entries

Ashutosh Bapat writes: > While reviewing patch for similar problem in postgres_fdw [1], I > noticed that we don't use positional notation while creating the view. > This might introduced anomalies when GROUP BY entries are > non-immutable. Yeah, we probably ought

Re: Does XMLSERIALIZE output xmlattributes in a stable order?

Chapman Flack writes: > Suppose I have a query that generates some XML content, and I want > to do this on a periodic schedule and check the resulting XML into > a version control system. > ... > But then, there are the attributes of elements. Order of attributes > is not

Does XMLSERIALIZE output xmlattributes in a stable order?

Suppose I have a query that generates some XML content, and I want to do this on a periodic schedule and check the resulting XML into a version control system. To avoid spurious diffs, I know I can control the order of child elements generated by xmlagg by slipping an ORDER BY into the aggregate

Re: Inlining functions with "expensive" parameters

I wrote: > Robert Haas writes: >> I don't quite follow the need for this. I mean, if we just stick a >> Param reference in there and create a corresponding InitPlan, the >> Param will be evaluated on demand, right? Is the point of the new >> node to make sure that the

Re: Inlining functions with "expensive" parameters

Robert Haas writes: > On Thu, Nov 16, 2017 at 2:51 PM, Andres Freund wrote: >> Right, but it doesn't sound that hard to introduce. Basically there'd >> need to be a WithParamValue node, that first evaluates parameters and >> then executes the child

Re: IndexTupleDSize macro seems redundant

On Mon, Nov 20, 2017 at 9:01 PM, Ildar Musin wrote: > Hi all, > > While I was looking through the indexes code I got confused by couple of > macros - IndexTupleSize() and IndexTupleDSize() - which seem to do the same > thing with only difference that the first one takes

Re: [HACKERS] Partition-wise aggregation/grouping

On Fri, Nov 17, 2017 at 7:24 AM, Ashutosh Bapat wrote: > + * this value should be multiplied with cpu_tuple_cost wherever applicable. > + */ > +#define DEFAULT_APPEND_COST_FACTOR 0.5 > > I am wondering whether we should just define > #define APPEND_TUPLE_COST

[PATCH] using arc4random for strong randomness matters.

Hello, This is my first small personal contribution. Motivation : - Using fail-safe, file descriptor free solution on *BSD and Darwin system - Somehow avoiding at the moment FreeBSD as it still uses RC4 (seemingly updated to Chacha20 for FreeBSD 12.0 and eventually backported later on). - For

Re: [HACKERS] Parallel Append implementation

On Tue, Nov 21, 2017 at 2:22 PM, Amit Khandekar wrote: > On 21 November 2017 at 12:44, Rafia Sabih > wrote: >> On Mon, Nov 13, 2017 at 12:54 PM, Amit Khandekar >> wrote: >>> Thanks a lot Robert for the patch. I will

Re: Failed to delete old ReorderBuffer spilled files

Hello, At Tue, 21 Nov 2017 20:27:25 +0900, atorikoshi wrote in > Thanks for reviewing! > > > On 2017/11/21 18:12, Masahiko Sawada wrote: > > On Tue, Nov 21, 2017 at 3:48 PM, Masahiko Sawada > >

Re: [HACKERS] path toward faster partition pruning

On Fri, Nov 17, 2017 at 3:31 PM, Amit Langote wrote: > > Support for hash partitioning and tests for the same. Also, since > update/delete on partitioned tables still depend on constraint exclusion > for pruning, fix things such that get_relation_constraints

Re: [HACKERS] path toward faster partition pruning

Thank you and sorry for the confused comments. At Mon, 13 Nov 2017 18:46:28 +0900, Amit Langote wrote in <8460a6c3-68c5-b78a-7d18-d253180f2...@lab.ntt.co.jp> > Horiguchi-san, > > Thanks for taking a look. Replying to all your emails here. > > In 0003, > > >

Re: default range partition and constraint exclusion

On 2017/11/18 8:28, Robert Haas wrote: > On Fri, Nov 17, 2017 at 12:57 AM, Amit Langote > wrote: >> While working on the patch for partition pruning for declarative >> partitioned tables, I noticed that default range partition will fail to be >> included in a plan

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

2017-11-14 18:42 GMT+01:00 Tom Lane : > You might consider putting the rewriting into, um, the rewriter. > It could be a separate pass after view expansion, if direct integration > with the existing behavior seems unduly spaghetti-ish.  Or do it in > an early phase of planning