Re: [HACKERS] Parallel Index Scans

On Sat, Jan 21, 2017 at 1:15 AM, Robert Haas wrote: > On Fri, Jan 20, 2017 at 9:29 AM, Amit Kapila wrote: >> Sure, if scan keys have changed then we can't continue, but this is >> the case where runtime keys are first time initialized. >> >> if

Re: [HACKERS] Failure in commit_ts tap tests

On Sat, Jan 21, 2017 at 12:45 AM, Tom Lane wrote: > > > Even more interesting, the warning appears as-expected in stripped down > test cases, eg > > $ perl -e 'use warnings; use Test::More; ok("Foo" ne "bar", "ok");' > ok 1 - ok > # Tests were run but no plan was declared and

Re: [HACKERS] Packages: Again

2017-01-20 17:01 GMT+01:00 Joshua D. Drake : > On 01/17/2017 09:26 AM, Robert Haas wrote: > >> On Fri, Jan 13, 2017 at 7:24 PM, Peter Geoghegan wrote: >> >>> MERGE isn't UPSERT, and isn't even in competition with UPSERT as a >>> feature. I've written

Re: [HACKERS] Off-by-one oddity in minval for decreasing sequences

On Sat, Jan 21, 2017 at 10:20 AM, Peter Eisentraut wrote: > On 1/6/17 2:15 PM, Daniel Verite wrote: >> I notice that there's a preexisting >> oddity in the fact that sequences created with a negative increment >> in current releases initialize the minval to

Re: [HACKERS] Measuring replay lag

On Tue, Jan 17, 2017 at 7:45 PM, Fujii Masao wrote: > On Thu, Dec 22, 2016 at 6:14 AM, Thomas Munro > wrote: >> On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao wrote: >>> I agree that the capability to measure the

Re: [HACKERS] Off-by-one oddity in minval for decreasing sequences

On 1/6/17 2:15 PM, Daniel Verite wrote: > I notice that there's a preexisting > oddity in the fact that sequences created with a negative increment > in current releases initialize the minval to -(2^63)+1 instead of -2^63, > the actual lowest value for a bigint. I think that had to do with that

[HACKERS] remote_apply for logical replication?

Hi, In src/backend/replication/logical/worker.c: pq_sendbyte(reply_message, 'r'); pq_sendint64(reply_message, recvpos); /* write */ pq_sendint64(reply_message, flushpos); /* flush */ pq_sendint64(reply_message, writepos); /* apply */ Is 'writepos' really applied?

Re: [HACKERS] Valgrind-detected bug in partitioning code

Robert Haas writes: > The difference is that those other equalBLAH functions call a > carefully limited amount of code whereas, in looking over the > backtrace you sent, I realized that equalPartitionDescs is calling > partition_bounds_equal which does this: >

Re: [HACKERS] increasing the default WAL segment size

On Sat, Jan 21, 2017 at 4:50 AM, Robert Haas wrote: > On Fri, Jan 20, 2017 at 2:34 AM, Michael Paquier > wrote: >> On Fri, Jan 20, 2017 at 12:49 AM, Robert Haas wrote: >>> On Wed, Jan 18, 2017 at 12:42 PM, Robert Haas

Updating MATERIALIZED VIEWs (Re: [HACKERS] delta relations in AFTER triggers)

[Looking at your patch I see that it's not quite related to MVs, so I'm changing the Subject. Apologies for the noise.] [Responding out of order.] On Fri, Jan 20, 2017 at 03:37:20PM -0600, Kevin Grittner wrote: > On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams wrote: > >

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

A couple things occurred to me after hitting "Send". In addition to the prior 2 points: (3) The documentation for max_pred_locks_per_relation needs a fix. Both page locks and tuple locks for the relation are counted toward the limit. In releases prior to this patch, max_pred_locks_per_relation

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

On Thu, Jan 5, 2017 at 12:19 PM, Tom Lane wrote: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: >>> One thing I don't like about this patch is that if a user has increased >>>

Re: [HACKERS] Valgrind-detected bug in partitioning code

On Fri, Jan 20, 2017 at 4:30 PM, Tom Lane wrote: > Stephen Frost writes: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> Robert Haas writes: Hmm. That's bad. I kind of wonder how sane it is to think that we can invoke

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams wrote: > On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote: >> There is currently plenty of room for pseudo-MV implementations, >> and may be for a while. It's a good indication of the need for the >> feature in

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

Alvaro Herrera wrote: > There was no discussion whatsoever of the "prefetch" patch in this > thread; and as far as I can see, nobody even mentioned such an idea in > the thread. This prefetch patch appeared out of the blue and there was > no discussion about it that I can see. Now I was about

Re: [HACKERS] Logical Replication WIP

On 20/01/17 17:23, Petr Jelinek wrote: > On 20/01/17 15:08, Peter Eisentraut wrote: >> On 1/19/17 5:01 PM, Petr Jelinek wrote: >>> There were some conflicting changes committed today so I rebased the >>> patch on top of them. >>> >>> Other than that nothing much has changed, I removed the separate

Re: [HACKERS] Valgrind-detected bug in partitioning code

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Robert Haas writes: >>> Hmm. That's bad. I kind of wonder how sane it is to think that we >>> can invoke SQL-callable functions during a relcache reload, >> You're doing WHAT? > Uh.

Re: [HACKERS] Declarative partitioning - another take

On Fri, Jan 20, 2017 at 1:15 AM, Andres Freund wrote: > On 2017-01-19 14:18:23 -0500, Robert Haas wrote: >> Committed. > > One of the patches around this topic committed recently seems to cause > valgrind failures like >

Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

On Fri, Jan 20, 2017 at 2:43 AM, Michael Paquier wrote: > On Fri, Jan 20, 2017 at 4:11 AM, Alvaro Herrera > wrote: >> Robert Haas wrote: >> >>> After sleeping on this, I'm inclined to go with Amit's fix for now. >>> It seems less likely to

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

You posted two patches with this preamble: Claudio Freire wrote: > Attached is the raw output of the test, the script used to create it, > and just in case the patch set used. I believe it's the same as the > last one I posted, just rebased. There was no discussion whatsoever of the "prefetch"

Re: [HACKERS] Valgrind-detected bug in partitioning code

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > Hmm. That's bad. I kind of wonder how sane it is to think that we > > can invoke SQL-callable functions during a relcache reload, because > > couldn't we be processing an invalidation in the context of an

Re: [HACKERS] Valgrind-detected bug in partitioning code

Robert Haas writes: > Hmm. That's bad. I kind of wonder how sane it is to think that we > can invoke SQL-callable functions during a relcache reload, because > couldn't we be processing an invalidation in the context of an aborted > transaction? You're doing WHAT?

Re: [HACKERS] pg_hba_file_settings view patch

Haribabu Kommi writes: > [ pg_hba_rules_10.patch ] I took a quick look over this. * I'm not exactly convinced that the way you approached the error message reporting, ie duplicating the logged message, is good. In particular this results in localizing the strings

Re: [HACKERS] Valgrind-detected bug in partitioning code

On Fri, Jan 20, 2017 at 8:09 AM, Tom Lane wrote: > skink has been unhappy since commit d26fa4f went in, but I think > that just exposed a pre-existing bug. Running valgrind here > duplicates the failure: > > ==00:00:02:01.653 16626== Conditional jump or move depends on

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/20/2017 04:18 AM, Ashutosh Sharma wrote: okay, Thanks for confirming that. I would like to update you that I am not able to reproduce this issue at my end. I suspect that the steps i am following might be slightly different than your's. Could you please have a look at steps

Re: [HACKERS] delta relations in AFTER triggers

On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote: > On Thu, Jan 19, 2017 at 4:14 PM, Nico Williams wrote: > > Reviews welcome! I will review. > There is currently plenty of room for pseudo-MV implementations, > and may be for a while. It's a good

Re: [HACKERS] PoC: Grouped base relation

On Thu, Jan 19, 2017 at 2:19 AM, Tomas Vondra wrote: >> Not all aggregates have TransValue * integer = newTransValue >> behaviour. Example is array_agg() or string_agg() has "TransValue >> concatenated integer time" behaviour. Or an aggregate "multiplying" >> values

Re: [HACKERS] Logical Replication WIP

On Fri, Jan 20, 2017 at 2:57 PM, Craig Ringer wrote: > > I don't see how a subscription can do anything useful with wal_level < > > logical? > > The upstream must have it set to logical so we can decide the change stream. > > The downstream need not. It's an independent

Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1

On Thu, Jan 19, 2017 at 9:39 PM, Tom Lane wrote: > If I had to bet on the basis of this much info, I would bet that the > parallel-query infrastructure is dropping the ball somewhere and > transmitting a corrupted datum that accidentally looks like it is > an expanded-object

Re: [HACKERS] Logical Replication WIP

On 21 Jan. 2017 06:48, "Robert Haas" wrote: On Fri, Jan 20, 2017 at 11:39 AM, Petr Jelinek wrote: > Launcher is needed for subscriptions, subscriptions don't depend on > wal_level. I don't see how a subscription can do anything useful with

Re: [HACKERS] increasing the default WAL segment size

On Fri, Jan 20, 2017 at 2:34 AM, Michael Paquier wrote: > On Fri, Jan 20, 2017 at 12:49 AM, Robert Haas wrote: >> On Wed, Jan 18, 2017 at 12:42 PM, Robert Haas wrote: >>> Problems 2-4 actually have to do with a

Re: [HACKERS] Logical Replication WIP

On Fri, Jan 20, 2017 at 11:39 AM, Petr Jelinek wrote: > Launcher is needed for subscriptions, subscriptions don't depend on > wal_level. I don't see how a subscription can do anything useful with wal_level < logical? -- Robert Haas EnterpriseDB:

Re: [HACKERS] Parallel Index Scans

On Fri, Jan 20, 2017 at 9:29 AM, Amit Kapila wrote: > Sure, if scan keys have changed then we can't continue, but this is > the case where runtime keys are first time initialized. > > if (node->iss_NumRuntimeKeys != 0 && !node->iss_RuntimeKeysReady) > > In the above

Re: [HACKERS] delta relations in AFTER triggers

On Thu, Jan 19, 2017 at 4:14 PM, Nico Williams wrote: > I hope what I've done about delta relations will be mostly irrelevant > given your patch (which I've not looked at in detail), Reviews welcome! > but just FYI, > I've built an alternate, all-SQL-coded materialized

Re: [HACKERS] delta relations in AFTER triggers

Attached is v10 which fixes bitrot from v9 caused by ea15e186. Still needs review. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company transition-v10.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Failure in commit_ts tap tests

Alvaro Herrera writes: > Hmm. The test works fine for me, even if it should be obvious that the > use of the != operator is wrong. I don't understand why it causes a > failure only for you. Even more interesting, the warning appears as-expected in stripped down test

Re: [HACKERS] Failure in commit_ts tap tests

Pavan Deolasee wrote: > Argument "" isn't numeric in numeric ne (!=) at t/004_restart.pl line 57. > Argument "Fri Jan 20 07:59:52.322811 2017 PST" isn't numeric in numeric ne > (!=) at t/004_restart.pl line 57. > not ok 8 - commit timestamp recorded > > Changing the operator to "ne" works for

Re: [HACKERS] Failure in commit_ts tap tests

Pavan Deolasee writes: > I'm surprised nobody reported this problem earlier. It looks like at least part of the answer is that the buildfarm isn't running this test. AFAICS, it runs "make installcheck" not "make check" in src/test/modules. I don't know whether any of

Re: [HACKERS] Failure in commit_ts tap tests

Pavan Deolasee writes: > I see a consistent failure while running "make -C > src/test/modules/commit_ts/ check" on a server compiled with > --enable-tap-tests. This is on the master branch (193a7d791) > ... > Changing the operator to "ne" works for me (patch attached).

Re: [HACKERS] Logical Replication WIP

On 20 January 2017 at 11:39, Petr Jelinek wrote: > On 20/01/17 17:33, Jaime Casanova wrote: >>> >> >> surely wal_level < logical shouldn't start a logical replication >> launcher, and after an initdb wal_level is only replica >> > > Launcher is needed for

[HACKERS] Failure in commit_ts tap tests

I see a consistent failure while running "make -C src/test/modules/commit_ts/ check" on a server compiled with --enable-tap-tests. This is on the master branch (193a7d791) t/004_restart.pl 1..16 ok 1 - getting ts of InvalidTransactionId reports error ok 2 - expected error from

Re: [HACKERS] pgbench more operators & functions

Rebased version after small expression scanner change. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 1eee8dc..8bb9c75 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -828,11 +828,11 @@ pgbench options dbname

Re: [HACKERS] Logical Replication WIP

On 20/01/17 17:33, Jaime Casanova wrote: > On 20 January 2017 at 11:25, Petr Jelinek > wrote: >> On 20/01/17 17:05, Fujii Masao wrote: >>> On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut >>> wrote: On 1/19/17 5:01 PM, Petr

Re: [HACKERS] Logical Replication WIP

On 20 January 2017 at 11:25, Petr Jelinek wrote: > On 20/01/17 17:05, Fujii Masao wrote: >> On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut >> wrote: >>> On 1/19/17 5:01 PM, Petr Jelinek wrote: There were some conflicting

Re: [HACKERS] Logical Replication WIP

On 20/01/17 17:05, Fujii Masao wrote: > On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut > wrote: >> On 1/19/17 5:01 PM, Petr Jelinek wrote: >>> There were some conflicting changes committed today so I rebased the >>> patch on top of them. >>> >>> Other than

Re: [HACKERS] Logical Replication WIP

On 20/01/17 15:08, Peter Eisentraut wrote: > On 1/19/17 5:01 PM, Petr Jelinek wrote: >> There were some conflicting changes committed today so I rebased the >> patch on top of them. >> >> Other than that nothing much has changed, I removed the separate sync >> commit patch, included the rename

Re: [HACKERS] pgbench - allow backslash continuations in \set expressions

Fabien COELHO writes: >> Probably the easiest fix is to add a rule that explicitly matches this >> situation: >> {nonspace}+{continuation} { ... throw back 2 chars and return the rest ... } > Well, as the continuation characters must be ignored, so there is no need > to

Re: [HACKERS] Fix documentation typo

On Fri, Jan 20, 2017 at 8:02 PM, Ishii Ayumi wrote: > Hi, > >> Here is a patch that adds temporary column's description to >> pg_replication_slots document. > > Attached patch is updated version to add detailed description. > > Regards, > -- > Ayumi Ishii > > 2017-01-19

Re: [HACKERS] Logical Replication WIP

On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut wrote: > On 1/19/17 5:01 PM, Petr Jelinek wrote: >> There were some conflicting changes committed today so I rebased the >> patch on top of them. >> >> Other than that nothing much has changed, I removed the

Re: [HACKERS] Packages: Again

On 01/17/2017 09:26 AM, Robert Haas wrote: On Fri, Jan 13, 2017 at 7:24 PM, Peter Geoghegan wrote: MERGE isn't UPSERT, and isn't even in competition with UPSERT as a feature. I've written reams of text explaining why this is so in precise detail, ... Hello, This is the

[HACKERS] logical-replication.sgml improvements

logical-replication.sgml.diff changes Erik Rijkers--- doc/src/sgml/logical-replication.sgml.orig 2017-01-20 16:46:25.0 +0100 +++ doc/src/sgml/logical-replication.sgml 2017-01-20 16:46:55.0 +0100 @@ -24,7 +24,7 @@ - Logical replication sends the changes on the publisher

Re: [HACKERS] Error building docs

Andreas Joseph Krogh writes: > I'm getting this error building docs (from commit > e4c27f5befbfc80a1bf96fc93256dce08b148238): Did it work for you before? > osx -D. -x lower -i include-xslt-index postgres.sgml >postgres.xmltmp > osx:postgres.sgml:3:55:W: cannot generate

[HACKERS] Error building docs

Hi,   I'm getting this error building docs (from commit e4c27f5befbfc80a1bf96fc93256dce08b148238):   $ make docs   make -C doc all make[1]: Entering directory '/home/andreak/dev/postgresql/doc' make -C src all make[2]: Entering directory '/home/andreak/dev/postgresql/doc/src' make -C sgml

Re: [HACKERS] Parallel Index Scans

On Fri, Jan 20, 2017 at 3:41 AM, Robert Haas wrote: > On Wed, Jan 18, 2017 at 8:03 AM, Amit Kapila wrote: >>> Why do we need separate AM support for index_parallelrescan()? Why >>> can't index_rescan() cover that case? >> >> The reason is that

Re: [HACKERS] Logical Replication WIP

On 1/19/17 5:01 PM, Petr Jelinek wrote: > There were some conflicting changes committed today so I rebased the > patch on top of them. > > Other than that nothing much has changed, I removed the separate sync > commit patch, included the rename patch in the patchset and fixed the > bug around

Re: [HACKERS] Improvements in psql hooks for variables

"Daniel Verite" writes: > Setting ENCODING has no effect, like DBNAME, USER, HOST and PORT. > In a way, it's a read-only variable that's here to inform the user, > not as a means to change the encoding (\encoding does that and > has proper support for tab completion)

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

Thanks tom, I confirm that ba61a04 fixes the issue. Now CI is passing. Jorge Solórzano me.jorsol.com On Thu, Jan 19, 2017 at 6:09 PM, Tom Lane wrote: > I wrote: > > Hmm ... that line was

Re: [HACKERS] Improvements in psql hooks for variables

Ashutosh Sharma wrote: > postgres=# \echo :ENCODING > UTF8 > postgres=# \set ENCODING xyz > postgres=# \echo :ENCODING > xyz > > I think currently we are not even showing what are the different valid > encoding names to the end users like we show it for other built-in > variables >

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

Peter Eisentraut wrote: > On 1/19/17 10:06 AM, Alvaro Herrera wrote: > >> Also, I wonder whether we should not in vacuum.c change the order of the > >> calls of SetTransactionIdLimit() and SetMultiXactIdLimit() as well, just > >> to keep everything consistent. > > > > I am wary of doing that.

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Fri, Jan 20, 2017 at 10:11 PM, Alvaro Herrera wrote: >> diff --git a/src/backend/replication/basebackup.c >> b/src/backend/replication/basebackup.c > >> @@ -148,6 +149,9 @@ static const char *excludeFiles[] = >> /* Skip auto conf temporary file. */ >>

Re: [HACKERS] Patch to implement pg_current_logfile() function

> diff --git a/src/backend/replication/basebackup.c > b/src/backend/replication/basebackup.c > @@ -148,6 +149,9 @@ static const char *excludeFiles[] = > /* Skip auto conf temporary file. */ > PG_AUTOCONF_FILENAME ".tmp", > > + /* Skip current log file temporary file */ > +

[HACKERS] Valgrind-detected bug in partitioning code

skink has been unhappy since commit d26fa4f went in, but I think that just exposed a pre-existing bug. Running valgrind here duplicates the failure: ==00:00:02:01.653 16626== Conditional jump or move depends on uninitialised value(s) ==00:00:02:01.653 16626==at 0x4BDF6B: btint4cmp

Re: [HACKERS] pgbench - allow backslash continuations in \set expressions

You have rules for {nonspace}+ [...] {continuation} Remember that flex always takes the rule that produces the longest match starting at the current point. {space}+ and {newline} don't conflict with continuations, but {nonspace}+ does: Indeed, I totally overlooked

Re: [HACKERS] Improvements in psql hooks for variables

Hi, I had a quick look into this patch and it seems to me like it takes care of all the built-in variables except ENCODING type. I think we need to apply such rule for ENCODING variable too. postgres=# \echo :ENCODING UTF8 postgres=# \set ENCODING xyz postgres=# \echo :ENCODING xyz I think

Re: [HACKERS] [ patch ] pg_dump: new --custom-fetch-table and --custom-fetch-value parameters

>> I have solve it adding two new parameters, --custom-fetch-table and >> --custom-fetch-value, to fetch less records for the specified table(s). > Giving the user the ability to change the fetch size sounds interesting, > though do we really need to specify it per table? What about just a >

Re: [HACKERS] Fix documentation typo

Hi, > Here is a patch that adds temporary column's description to > pg_replication_slots document. Attached patch is updated version to add detailed description. Regards, -- Ayumi Ishii 2017-01-19 15:56 GMT+09:00 Ishii Ayumi : > Hi, > > Here is a patch that adds

Re: [HACKERS] Parallel Index Scans

On Fri, Jan 20, 2017 at 12:59 AM, Robert Haas wrote: > On Thu, Jan 19, 2017 at 4:26 AM, Amit Kapila wrote: >> Fixed. > > > If all of that were no issue, the considerations in > TargetListSupportsBackwardScan could be a problem, too. But I think >

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Thu, Jan 19, 2017 at 8:31 PM, Claudio Freire wrote: > On Thu, Jan 19, 2017 at 6:33 AM, Anastasia Lubennikova > wrote: >> 28.12.2016 23:43, Claudio Freire: >> >> Attached v4 patches with the requested fixes. >> >> >> Sorry for being late,

Re: [HACKERS] Microvacuum support for Hash Index

Hi Jesper, > I'm not seeing this deadlock with just the WAL v8 patch applied. > okay, Thanks for confirming that. I would like to update you that I am not able to reproduce this issue at my end. I suspect that the steps i am following might be slightly different than your's. Could you please

Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG

> Idehira-san, this is a very intrusive patch... It really needs a specific > reviewer to begin with, but really it would be nice if you could review > someone > else's patch, with a difficulty rather equivalent to what we have here. Michael, thank you for taking a look at my patch and giving me

[HACKERS] Fix a comment in feelist.c

Hi, I've found a mistake in a comment of StrategyNotifyBgWriter in freelist.c. bgwriterLatch was replaced by bgwprocno in the following commit, but this is remained in the comment. commit d72731a70450b5e7084991b9caa15cb58a2820df Author: Andres Freund Date: Thu Dec 25

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Thu, Jan 19, 2017 at 6:17 PM, Simon Riggs wrote: > We seem to be caught between adding lots of new things as parameters > and adding new detail into pg_hba.conf. > > Parameters like password_encryption are difficult here because they > essentially repeat what has already