Re: [HACKERS] Inefficient shutdown of pg_basebackup

On 27 April 2017 at 05:31, Tom Lane wrote: > The attached draft patch fixes this by expanding the StreamCtl API > with a socket that the low-level wait routine should check for input. > For me, this consistently knocks about 10 seconds off the runtime of > 001_stream_rep.pl.

Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c

On 02/05/17 20:43, Robert Haas wrote: > On Thu, Apr 20, 2017 at 2:58 PM, Peter Eisentraut > wrote: >> On 4/16/17 16:11, Petr Jelinek wrote: >>> Yeah it is, it needs to be fenced to happen only after commit, which is >>> not guaranteed at the point of code, we

Re: [HACKERS] Time based lag tracking for logical replication

On 23 April 2017 at 01:10, Petr Jelinek wrote: > Hi, > > The time based lag tracking commit [1] added interface for logging > progress of replication so that we can report lag as time interval > instead of just bytes. But the patch didn't contain patch for the >

Re: [HACKERS] Time based lag tracking for logical replication

On Wed, May 3, 2017 at 6:28 PM, Simon Riggs wrote: > On 23 April 2017 at 01:10, Petr Jelinek wrote: >> Hi, >> >> The time based lag tracking commit [1] added interface for logging >> progress of replication so that we can report lag as time

Re: [HACKERS] Time based lag tracking for logical replication

On 03/05/17 08:28, Simon Riggs wrote: > On 23 April 2017 at 01:10, Petr Jelinek wrote: >> Hi, >> >> The time based lag tracking commit [1] added interface for logging >> progress of replication so that we can report lag as time interval >> instead of just bytes. But

Re: [HACKERS] proposal psql \gdesc

2017-04-28 6:08 GMT+02:00 Pavel Stehule : > Hi > > Sometimes I have to solve the result types of some query. It is invisible > in psql. You have to materialize table or you have to create view. Now, > when we can enhance \g command, we can introduce query describing > >

Re: [HACKERS] [POC] hash partitioning

On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote: >I spent some time today looking at these patches. It seems like there >is some more work still needed here to produce something committable >regardless of which way we go, but I am inclined to think that Amul's >patch

Re: [HACKERS] password_encryption, default and 'plain' support

On Wed, May 3, 2017 at 7:31 AM, Heikki Linnakangas wrote: > In various threads on SCRAM, we've skirted around the question of whether we > should still allow storing passwords in plaintext. I've avoided discussing > that in those other threads, because it's been an orthogonal

Re: [HACKERS] CTE inlining

On Wed, May 3, 2017 at 11:31 AM, David Fetter wrote: > On Wed, May 03, 2017 at 11:26:27AM -0300, Claudio Freire wrote: >> On Wed, May 3, 2017 at 2:19 AM, Craig Ringer wrote: >> >> Or we will choose WITH MATERIALIZE, and then the users aware of >> >> the

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

Robert Haas wrote: > I suspect that most users would find it more useful to capture all of > the rows that the statement actually touched, regardless of whether > they hit the named table or an inheritance child. Yes, agreed. For the plain inheritance cases each row would need to have an

Re: [HACKERS] CTE inlining

> I could tolerate telling people to use OFFSET 0 (and documenting it!) > as a workaround if we can't get something more friendly in. I agree with that. > If we go with WITH INLINE then we're likely not solving anything, because > most people will simply use WITH just like now, and will be

Re: [HACKERS] Cost of src/test/recovery and .../subscription tests

On Wed, Apr 19, 2017 at 1:28 PM, Tom Lane wrote: > So I updated longfin to the new release of the buildfarm client, > and was quite dismayed by the fact that its cycle time went > from 16 minutes to 24. Some of that might be random effects like > the state of the kernel disk

Re: [HACKERS] password_encryption, default and 'plain' support

Robert Haas writes: > On Wed, May 3, 2017 at 7:31 AM, Heikki Linnakangas wrote: >> So, I propose that we remove support for password_encryption='plain' in >> PostgreSQL 10. If you try to do that, you'll get an error. > I have no idea how widely used that

[HACKERS] WIP Patch: Precalculate stable functions, infrastructure v1

Hello everyone again! This is the continuation of my previous patch on the same topic; here there are changes made thanks to Tom Lane comments (see thread here [1]). To not send big patch I have split it (that's why version starts with the first again) and here I send infrastructure patch

Re: [HACKERS] WITH clause in CREATE STATISTICS

Simon Riggs wrote: > 2. > USING keyword, no brackets > CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1 > WHERE partial-stuff; > > and if there are options, use the WITH for the optional parameters like this > CREATE STATISTICS s1 USING (dependencies, ndistinct) WITH

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Tue, May 2, 2017 at 9:44 PM, Thomas Munro wrote: > I think that we should only capture transition tuples captured from > the explicitly named relation, since we only fire AFTER STATEMENT > triggers on that relation. I see no inconsistency with the policy of >

Re: [HACKERS] Cost of src/test/recovery and .../subscription tests

Robert Haas writes: > On Wed, Apr 19, 2017 at 1:28 PM, Tom Lane wrote: >> I am going to say flat out that that's unacceptably long for >> a test script that will be run dozens of times a day by the >> buildfarm. There isn't any other test script that

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 3, 2017 at 12:02 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> I suspect that most users would find it more useful to capture all of >> the rows that the statement actually touched, regardless of whether >> they hit the named table or an inheritance

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 03, 2017 at 11:47:04AM -0400, Robert Haas wrote: > On Tue, May 2, 2017 at 9:44 PM, Thomas Munro > wrote: > > I think that we should only capture transition tuples captured from > > the explicitly named relation, since we only fire AFTER STATEMENT > >

Re: [HACKERS] password_encryption, default and 'plain' support

On Wed, May 3, 2017 at 8:38 PM, Magnus Hagander wrote: > On Wed, May 3, 2017 at 1:31 PM, Heikki Linnakangas wrote: >> In various threads on SCRAM, we've skirted around the question of whether >> we should still allow storing passwords in plaintext. I've

Re: [HACKERS] CTE inlining

On 05/02/2017 07:00 PM, Tomas Vondra wrote: > > > > I think we agree that: > > * Just removing the optimization fence and telling users to use OFFSET > 0 instead is a no-go, just like removing the fencing and not providing > any sensible replacement. > > * GUC is not the solution. yes > >

[HACKERS] Error message on missing SCRAM authentication with older clients

Currently, if you use 9.6 libpq to connect to a v10 server that requires SCRAM authentication, you get an error: psql: authentication method 10 not supported I'd like to apply this small patch to all the stable branches, to give a nicer error message: psql: SCRAM authentication not

Re: [HACKERS] scram and \password

On Wed, May 3, 2017 at 5:26 PM, Heikki Linnakangas wrote: > Ok, gotcha. I disagree, I think we should provide a default. Libpq is in a > better position to make a good choice than most applications. > > I've committed the new PQencryptPasswordConn function, with the default >

Re: [HACKERS] Error message on missing SCRAM authentication with older clients

Hi Magnus, > +1, even though it's not strictly speaking a bugfix to go in a backpatch, I > think it will help enough users that it's worth doing. And I can't see how > it could possibly be unsafe... Well, strictly speaking there could be applications that parse error messages using regular

Re: [HACKERS] [PostgreSQL 10] default of hot_standby should be "on"?

Hi, On Tue, May 02, 2017 at 11:13:58AM +0200, Magnus Hagander wrote: > Looks good to me as well. Applied, with only a minor further docs addition > saying that this is the default also on the high availability page. I understand this is late, but a colleague alerted me to the following behaviour

Re: [HACKERS] Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode

Hi Craig, On Wed, May 3, 2017 at 10:50 AM, Craig Ringer wrote: > On 3 May 2017 at 12:32, Haribabu Kommi wrote: >> [Adding -hackers mailing list] >> >> On Fri, Apr 28, 2017 at 6:28 PM, wrote: >>> >>> The following bug

Re: [HACKERS] renaming "transaction log"

On 5/2/17 9:09 PM, Peter Eisentraut wrote: > Most documentation and error messages still uses the term "transaction > log" to refer to the write-ahead log. Here is a patch to rename that, > which I think should be done, to match the xlog -> wal renaming in APIs. +1 for the idea. The

Re: [HACKERS] renaming "transaction log"

Peter Eisentraut wrote: > Most documentation and error messages still uses the term "transaction > log" to refer to the write-ahead log. Here is a patch to rename that, > which I think should be done, to match the xlog -> wal renaming in APIs. +1 for the idea. I suggest grepping for

Re: [HACKERS] check with serial

Andrew Dunstan writes: > On 05/02/2017 10:13 PM, Vaishnavi Prabakaran wrote: >> And, now after your patch, do we still need "installcheck-parallel" >> command? It is redundant IMO, just give a thought. > I'd be quite happy to remove the target in favor of this

Re: [HACKERS] check with serial

On 05/03/2017 10:12 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 05/02/2017 10:13 PM, Vaishnavi Prabakaran wrote: >>> And, now after your patch, do we still need "installcheck-parallel" >>> command? It is redundant IMO, just give a thought. >> I'd be quite

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 02/05/17 16:14, Petr Jelinek wrote: > On 02/05/17 15:31, Tom Lane wrote: >> Petr Jelinek writes: >>> Let me expand, if we don't drop the slot by default when dropping >>> subscription, we'll have a lot of users with dead slots laying around >>> holding back

Re: [HACKERS] Error message on missing SCRAM authentication with older clients

On Wed, May 3, 2017 at 10:58 AM, Heikki Linnakangas wrote: > Currently, if you use 9.6 libpq to connect to a v10 server that requires > SCRAM authentication, you get an error: > > psql: authentication method 10 not supported > > I'd like to apply this small patch to all

Re: [HACKERS] Error message on missing SCRAM authentication with older clients

Hi Heikki, > psql: SCRAM authentication not supported by this version of libpq Maybe it would be better to specify a minimum required version? -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature

Re: [HACKERS] check with serial

On 05/02/2017 10:13 PM, Vaishnavi Prabakaran wrote: > > > On Tue, May 2, 2017 at 11:30 PM, Andrew Dunstan > > wrote: > > > Here's a simple patch that does what I had in mind. It allows > providing > for an

Re: [HACKERS] Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode

On Wed, May 3, 2017 at 3:20 PM, Craig Ringer wrote: > On 3 May 2017 at 12:32, Haribabu Kommi wrote: > > [Adding -hackers mailing list] > > > > On Fri, Apr 28, 2017 at 6:28 PM, wrote: > >> > >> The following bug has

Re: [HACKERS] password_encryption, default and 'plain' support

On Wed, May 3, 2017 at 2:25 PM, Michael Paquier wrote: > On Wed, May 3, 2017 at 8:38 PM, Magnus Hagander > wrote: > > On Wed, May 3, 2017 at 1:31 PM, Heikki Linnakangas > wrote: > >> In various threads on SCRAM, we've skirted

Re: [HACKERS] CTE inlining

On Wed, May 3, 2017 at 2:19 AM, Craig Ringer wrote: >> Or we will choose WITH MATERIALIZE, and then the users aware of the fencing >> (and using the CTEs for that purpose) will have to modify the queries. But >> does adding MATERIALIZE quality as major query rewrite? > >

Re: [HACKERS] CTE inlining

On Wed, May 03, 2017 at 11:26:27AM -0300, Claudio Freire wrote: > On Wed, May 3, 2017 at 2:19 AM, Craig Ringer wrote: > >> Or we will choose WITH MATERIALIZE, and then the users aware of > >> the fencing (and using the CTEs for that purpose) will have to > >> modify the

Re: [HACKERS] password_encryption, default and 'plain' support

Heikki Linnakangas writes: > On 05/03/2017 07:14 PM, Tom Lane wrote: >> Is it possible that there are still client libraries that don't support >> password encryption at all? If so, are we willing to break them? >> I'd say "yes" but it's worth thinking about. > That doesn't

Re: [HACKERS] How huge does mvtest_huge need to be?

On Wed, May 3, 2017 at 12:08 PM, Tom Lane wrote: > So ... is there a good reason to be using a large table here, and > if so what is it, and how big does the table really need to be > to provide useful test coverage? Hm. This seems like a particularly useless size. It

Re: [HACKERS] WITH clause in CREATE STATISTICS

Stephen Frost wrote: > > Here I add one, which seems to work for me. Pushed it -- I also added another one which specifies options, to test WITH handling in ruleutils. > > Considering that Stephen missed a terminating semicolon for test with > > create_order 96 (the last one prior to my commit)

Re: [HACKERS] renaming "transaction log"

On Wed, May 03, 2017 at 10:33:32AM -0700, David Fetter wrote: > On Wed, May 03, 2017 at 10:57:06AM -0300, Alvaro Herrera wrote: > > Peter Eisentraut wrote: > > > Most documentation and error messages still uses the term "transaction > > > log" to refer to the write-ahead log. Here is a patch to

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Alvaro Herrera wrote: > > > In the meantime, I noticed that pg_dump support for extstats is not > > covered, which I'll go fix next. > > Here I add one, which seems to work for me. > > Considering that Stephen missed a terminating

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera wrote: > Simon Riggs wrote: > > > 2. > > USING keyword, no brackets > > CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1 > > WHERE partial-stuff; > > > > and if there are options, use the WITH for the optional parameters like this > > CREATE STATISTICS s1

Re: [HACKERS] CTE inlining

On Wed, May 03, 2017 at 01:27:38PM -0300, Claudio Freire wrote: > On Wed, May 3, 2017 at 11:31 AM, David Fetter wrote: > > Are you aware of such an ORM which both supports WITH and doesn't > > also closely track PostgreSQL development? I'm not. > > > > Even assuming that such a

Re: [HACKERS] CTE inlining

2017-05-03 18:54 GMT+02:00 David Fetter : > On Wed, May 03, 2017 at 01:27:38PM -0300, Claudio Freire wrote: > > On Wed, May 3, 2017 at 11:31 AM, David Fetter wrote: > > > Are you aware of such an ORM which both supports WITH and doesn't > > > also closely

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera wrote: > In the meantime, I noticed that pg_dump support for extstats is not > covered, which I'll go fix next. Here I add one, which seems to work for me. Considering that Stephen missed a terminating semicolon for test with create_order 96 (the last one prior to my commit) in

Re: [HACKERS] CTE inlining

On Wed, May 03, 2017 at 02:33:05PM -0300, Alvaro Herrera wrote: > David Fetter wrote: > > > When we add a "temporary" GUC, we're taking on a gigantic burden. > > Either we support it forever somehow, or we put it on a deprecation > > schedule immediately and expect to be answering questions about

Re: [HACKERS] password_encryption, default and 'plain' support

On Wed, May 3, 2017 at 5:52 PM, Robert Haas wrote: > On Wed, May 3, 2017 at 7:31 AM, Heikki Linnakangas > wrote: > > In various threads on SCRAM, we've skirted around the question of > whether we > > should still allow storing passwords in plaintext. I've

[HACKERS] How huge does mvtest_huge need to be?

Continuing to investigate possible speedups of the regression tests, I noticed that some of the slower individual statements are those dealing with mvtest_huge and mvtest_hugeview in matview.sql. Cutting the size of mvtest_huge from 100K rows to 10K rows is enough to halve the overall runtime of

Re: [HACKERS] renaming "transaction log"

On Wed, May 03, 2017 at 10:57:06AM -0300, Alvaro Herrera wrote: > Peter Eisentraut wrote: > > Most documentation and error messages still uses the term "transaction > > log" to refer to the write-ahead log. Here is a patch to rename that, > > which I think should be done, to match the xlog -> wal

Re: [HACKERS] CTE inlining

David Fetter wrote: > When we add a "temporary" GUC, we're taking on a gigantic burden. > Either we support it forever somehow, or we put it on a deprecation > schedule immediately and expect to be answering questions about it for > years after it's been removed. > > -1 for the GUC. Absolutely.

Re: [HACKERS] password_encryption, default and 'plain' support

On 05/03/2017 07:14 PM, Tom Lane wrote: Robert Haas writes: On Wed, May 3, 2017 at 7:31 AM, Heikki Linnakangas wrote: So, I propose that we remove support for password_encryption='plain' in PostgreSQL 10. If you try to do that, you'll get an error.

Re: [HACKERS] renaming "transaction log"

David Fetter wrote: > On Wed, May 03, 2017 at 10:33:32AM -0700, David Fetter wrote: > > On Wed, May 03, 2017 at 10:57:06AM -0300, Alvaro Herrera wrote: > > > Peter Eisentraut wrote: > > > > Most documentation and error messages still uses the term "transaction > > > > log" to refer to the

Re: [HACKERS] CTE inlining

2017-05-03 19:33 GMT+02:00 Alvaro Herrera : > David Fetter wrote: > > > When we add a "temporary" GUC, we're taking on a gigantic burden. > > Either we support it forever somehow, or we put it on a deprecation > > schedule immediately and expect to be answering questions

Re: [HACKERS] How huge does mvtest_huge need to be?

I wrote: > Kevin Grittner writes: >> Hm. This seems like a particularly useless size. It would test a >> possibly useful corner case if it was over 10MB so that it was over >> vacuum's truncation threshold, but that would obviously be even >> slower. It doesn't seem

Re: [HACKERS] WITH clause in CREATE STATISTICS

Andrew Dunstan wrote: > On 05/03/2017 04:42 PM, Tom Lane wrote: > > One other point is that as long as we've got reserved keywords introducing > > each clause, there isn't actually an implementation reason why we couldn't > > accept the clauses in any order. Not sure I want to document it that

[HACKERS] PROVE_FLAGS

Can someone please explain to me why we have this in Makefile.global.in? (from commit e9c81b60 ) PROVE_FLAGS = ISTM it's unnecessary, and prevents us from using the same named value in the environment. I want to be able to use the environment in vcregress.pl, and I'd like the Make files

Re: [HACKERS] How huge does mvtest_huge need to be?

Kevin Grittner writes: > On Wed, May 3, 2017 at 12:08 PM, Tom Lane wrote: >> So ... is there a good reason to be using a large table here, and >> if so what is it, and how big does the table really need to be >> to provide useful test coverage? > Hm. This

Re: [HACKERS] PROVE_FLAGS

Andrew Dunstan writes: > Can someone please explain to me why we have this in Makefile.global.in? > (from commit e9c81b60 ) > PROVE_FLAGS = Before that commit it was like PROVE_FLAGS = --verbose which had some value. I agree that now we'd be better

Re: [HACKERS] CTE inlining

On Wed, May 3, 2017 at 12:33 PM, Alvaro Herrera wrote: > David Fetter wrote: > >> When we add a "temporary" GUC, we're taking on a gigantic burden. >> Either we support it forever somehow, or we put it on a deprecation >> schedule immediately and expect to be answering

Re: [HACKERS] PROVE_FLAGS

On 2017-05-03 15:14:27 -0400, Andrew Dunstan wrote: > > Can someone please explain to me why we have this in Makefile.global.in? > (from commit e9c81b60 ) > > > PROVE_FLAGS = > > > ISTM it's unnecessary, and prevents us from using the same named value > in the environment. I want to be

Re: [HACKERS] CTE inlining

On 05/03/2017 07:33 PM, Alvaro Herrera wrote: 1) we switch unmarked CTEs as inlineable by default in pg11. What seems likely to happen for a user that upgrades to pg11 is that 5 out of 10 CTE-using queries are going to become faster than with pg10, and they are going to be happy; 4 out of five

Re: [HACKERS] CTE inlining

On 05/03/2017 05:24 PM, Merlin Moncure wrote: > On Wed, May 3, 2017 at 12:33 PM, Alvaro Herrera > wrote: >> David Fetter wrote: >> >>> When we add a "temporary" GUC, we're taking on a gigantic burden. >>> Either we support it forever somehow, or we put it on a

Re: [HACKERS] CTE inlining

On 04/05/17 05:33, Alvaro Herrera wrote: David Fetter wrote: When we add a "temporary" GUC, we're taking on a gigantic burden. Either we support it forever somehow, or we put it on a deprecation schedule immediately and expect to be answering questions about it for years after it's been

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, Apr 20, 2017 at 10:27 AM, Ashutosh Bapat wrote: > The logs above show that 34 seconds elapsed between starting to abort > the transaction and knowing that the foreign server is unreachable. It > looks like it took that much time for the local server to

Re: [HACKERS] WITH clause in CREATE STATISTICS

On 05/03/2017 04:42 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Yawn. So, we have not achieved the stated goal which was to get rid of >> the ugly clause in the middle of the command; moreover we have gained >> *yet another* clause in the middle of the command.

Re: [HACKERS] PROVE_FLAGS

On 05/03/2017 03:21 PM, Andres Freund wrote: > On 2017-05-03 15:14:27 -0400, Andrew Dunstan wrote: >> Can someone please explain to me why we have this in Makefile.global.in? >> (from commit e9c81b60 ) >> >> >> PROVE_FLAGS = >> >> >> ISTM it's unnecessary, and prevents us from using the same

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera writes: > Yawn. So, we have not achieved the stated goal which was to get rid of > the ugly clause in the middle of the command; moreover we have gained > *yet another* clause in the middle of the command. Is this really an > improvement? We're trading

Re: [HACKERS] [PostgreSQL 10] default of hot_standby should be "on"?

On Wed, May 3, 2017 at 4:18 PM, Michael Banck wrote: > Hi, > > On Tue, May 02, 2017 at 11:13:58AM +0200, Magnus Hagander wrote: > > Looks good to me as well. Applied, with only a minor further docs > addition > > saying that this is the default also on the high

Re: [HACKERS] CTE inlining

On 5/3/17 9:54 PM, Andreas Karlsson wrote: On 05/03/2017 07:33 PM, Alvaro Herrera wrote: 1) we switch unmarked CTEs as inlineable by default in pg11. What seems likely to happen for a user that upgrades to pg11 is that 5 out of 10 CTE-using queries are going to become faster than with pg10,

Re: [HACKERS] How huge does mvtest_huge need to be?

On Wed, May 3, 2017 at 4:37 PM, Tom Lane wrote: > At this point I'm inclined to just delete the whole test. ok -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode

On Wed, May 3, 2017 at 10:44 PM, Ashutosh Sharma wrote: > Hi Craig, > > On Wed, May 3, 2017 at 10:50 AM, Craig Ringer > wrote: > > On 3 May 2017 at 12:32, Haribabu Kommi wrote: > >> [Adding -hackers mailing list] > >> > >>

Re: [HACKERS] WITH clause in CREATE STATISTICS

On 5/3/17 11:36 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: On 05/03/2017 04:42 PM, Tom Lane wrote: One other point is that as long as we've got reserved keywords introducing each clause, there isn't actually an implementation reason why we couldn't accept the clauses in any order.

Re: [HACKERS] password_encryption, default and 'plain' support

On Wed, May 3, 2017 at 9:57 PM, Magnus Hagander wrote: > > > On Wed, May 3, 2017 at 2:25 PM, Michael Paquier > wrote: >> >> On Wed, May 3, 2017 at 8:38 PM, Magnus Hagander >> wrote: >> > On Wed, May 3, 2017 at 1:31 PM, Heikki

Re: [HACKERS] GCC 7 warnings

On 4/10/17 11:03, Peter Eisentraut wrote: > The release of GCC 7 is approaching [0], and the number of warnings in > PostgreSQL has gone up since we last looked [1]. Output attached. (My > version is 7.0.1 20170408.) GCC 7 has been released. Should we backpatch these warning fixes? The commit

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 4/30/17 04:05, Noah Misch wrote: > The above-described topic is currently a PostgreSQL 10 open item. Peter, > since you committed the patch believed to have created it, you own this open > item. If some other commit is more relevant or if this does not belong as a > v10 open item, please let

[HACKERS] Reducing runtime of stats regression test

On a reasonably fast development machine, one of the biggest time sinks while running the core regression tests is the long "sleep" calls in the stats.sql regression test. I took a closer look at these, and I think we could basically get rid of them. First up is this bit at the beginning of that

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Hi Stephen, On Wed, May 3, 2017 at 12:05 PM, Stephen Frost wrote: > Amit, > > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: >> Attached updated patches. > > Please find an updated version which corrects the issue with > binary-upgrade of partitioned tables having

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Amit, * Amit Langote (amitlangot...@gmail.com) wrote: > On Wed, May 3, 2017 at 12:05 PM, Stephen Frost wrote: > > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > >> Attached updated patches. > > > > Please find an updated version which corrects the issue with > >

Re: [HACKERS] GCC 7 warnings

Peter Eisentraut writes: > On 4/10/17 11:03, Peter Eisentraut wrote: >> The release of GCC 7 is approaching [0], and the number of warnings in >> PostgreSQL has gone up since we last looked [1]. Output attached. (My >> version is 7.0.1 20170408.) > GCC 7 has

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Wed, May 3, 2017 at 3:49 PM, Robert Haas wrote: > It seems pretty clear to me that we are not going to fix all of these > issues in one patch. Here's a sketch of an idea for how to start > making things better: Patch attached. > - Add an in_abort_cleanup flag to

[HACKERS] Error message on missing SCRAM authentication with older clients

Currently, if you use 9.6 libpq to connect to a v10 server that requires SCRAM authentication, you get an error: psql: authentication method 10 not supported I'd like to apply this small patch to all the stable branches, to give a nicer error message: psql: SCRAM authentication not

Re: [HACKERS] Logical replication ApplyContext bloat

> On 20 Apr 2017, at 17:01, Dilip Kumar wrote: > > On Thu, Apr 20, 2017 at 7:04 PM, Stas Kelvich > wrote: >> Thanks for noting. >> >> Added short description of ApplyContext and ApplyMessageContext to README. > > Typo > > /analysys/analysis

Re: [HACKERS] scram and \password

On Wed, May 3, 2017 at 10:26 AM, Heikki Linnakangas wrote: > On 05/02/2017 07:47 PM, Robert Haas wrote: > >> On Tue, May 2, 2017 at 3:42 AM, Heikki Linnakangas >> wrote: >> >>> There's going to be a default, one way or another. The default is going >>> to >>>

Re: [HACKERS] scram and \password

On 05/02/2017 07:47 PM, Robert Haas wrote: On Tue, May 2, 2017 at 3:42 AM, Heikki Linnakangas wrote: There's going to be a default, one way or another. The default is going to come from password_encryption, or it's going to be a hard-coded value or logic based on

Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c

On 2017-05-03 08:17, Petr Jelinek wrote: On 02/05/17 20:43, Robert Haas wrote: On Thu, Apr 20, 2017 at 2:58 PM, Peter Eisentraut code path that calls CommitTransactionCommand() should have one, no? Is there anything left to be committed here? Afaics the fix was not committed. Peter

[HACKERS] password_encryption, default and 'plain' support

Hi, In various threads on SCRAM, we've skirted around the question of whether we should still allow storing passwords in plaintext. I've avoided discussing that in those other threads, because it's been an orthogonal question, but it's a good question and we should discuss it. So, I propose

Re: [HACKERS] password_encryption, default and 'plain' support

On Wed, May 3, 2017 at 1:31 PM, Heikki Linnakangas wrote: > Hi, > > In various threads on SCRAM, we've skirted around the question of whether > we should still allow storing passwords in plaintext. I've avoided > discussing that in those other threads, because it's been an

Re: [HACKERS] PROVE_FLAGS

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > Can someone please explain to me why we have this in Makefile.global.in? > > (from commit e9c81b60 ) > > PROVE_FLAGS = > > Before that commit it was like > > PROVE_FLAGS = --verbose

Re: [HACKERS] WITH clause in CREATE STATISTICS

On 3 May 2017 at 23:31, Andrew Dunstan wrote: >> It also seems like we don't need to have *both* fully-reserved keywords >> introducing each clause *and* parentheses around the lists. Maybe >> dropping the parens around the stats-types list and the column-names

Re: [HACKERS] [POC] hash partitioning

On Tue, May 2, 2017 at 7:01 PM, Robert Haas wrote: > On Tue, May 2, 2017 at 9:01 PM, Jeff Davis wrote: >> 1. Consider a partition-wise join of two hash-partitioned tables. If >> that's a hash join, and we just use the hash opclass, we immediately >> lose

Re: [HACKERS] snapbuild woes

On Thu, Apr 27, 2017 at 09:42:58PM -0700, Andres Freund wrote: > > > On April 27, 2017 9:34:44 PM PDT, Noah Misch wrote: > >On Fri, Apr 21, 2017 at 10:36:21PM -0700, Andres Freund wrote: > >> On 2017-04-17 21:16:57 -0700, Andres Freund wrote: > >> > I've since the previous