Re: [HACKERS] subscription worker doesn't start immediately on eabled

At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut wrote in <3d6a1bd0-08ce-301d-3336-ec9f623a3...@2ndquadrant.com> > On 4/6/17 08:24, Kyotaro HORIGUCHI wrote: > > The attached patch wakes up launcher when a subscription is > > enabled. This fails when a

Re: [HACKERS] some review comments on logical rep code

At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada wrote in > On Wed, Apr 26, 2017 at 12:35 PM, Petr Jelinek > wrote: > > On 26/04/17 01:01, Fujii Masao wrote: >

Re: [HACKERS] Cached plans and statement generalization

On 26.04.2017 00:47, Andres Freund wrote: On 2017-04-25 21:11:08 +, Doug Doole wrote: When I did this in DB2, I didn't use the parser - it was too expensive. I just tokenized the statement and used some simple rules to bypass the invalid cases. For example, if I saw the tokens "ORDER" and

[HACKERS] Fix a typo in subscriptioncmd.c

Hi, Attached patch for $subject. s/accomodate/accommodate/ Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center fix_typo_in_subscriptioncmd_c.patch Description: Binary data -- Sent via pgsql-hackers mailing list

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

On Wed, Apr 26, 2017 at 9:36 AM, Craig Ringer wrote: > On 26 April 2017 at 08:30, Huong Dangminh wrote: > >> Default for hot_standby parameter should be "on" from PostgreSQL 10? >> >> In PostgreSQL 10, -w option is default for [pg_ctl start]. >>

Re: [HACKERS] Cached plans and statement generalization

On 26.04.2017 01:34, Andres Freund wrote: Hi, (FWIW, on this list we don't do top-quotes) On 2017-04-25 22:21:22 +, Doug Doole wrote: Plan invalidation was no different than for any SQL statement. DB2 keeps a list of the objects the statement depends on. If any of the objects changes in

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Hi Stephen, On 2017/04/26 0:42, Stephen Frost wrote: > Amit, > > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: >> I think why getPartitions() is separate from getInherits() and then >> flagPartitions() separate from flagInhTables() is because I thought >> originally that mixing the two

Re: [HACKERS] Cached plans and statement generalization

On 26.04.2017 04:00, Tsunakawa, Takayuki wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Konstantin Knizhnik Well, first of all I want to share results I already get: pgbench with default parameters, scale 10 and one connection: So

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

At Tue, 25 Apr 2017 15:43:59 +0530, Ashutosh Bapat wrote in > On Tue, Apr 25, 2017 at 1:31 PM, Kyotaro HORIGUCHI > wrote: > >> > >> The logs above show that 34

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

On 26 April 2017 at 02:12, Peter Eisentraut wrote: > On 4/24/17 22:50, Peter Eisentraut wrote: >> On 4/14/17 00:24, Ashutosh Bapat wrote: >>> This looks better. Here are patches for master and 9.6. >>> Since join pushdown was supported in 9.6 the patch should be

Re: [HACKERS] an outdated comment for hash_seq_init.

At Tue, 25 Apr 2017 11:00:16 -0400, Robert Haas wrote in > On Mon, Apr 24, 2017 at 3:55 AM, Kyotaro HORIGUCHI > wrote: > > While I looked into dynahash.c, I found that

Re: [HACKERS] Quorum commit for multiple synchronous replication.

At Tue, 25 Apr 2017 21:21:29 +0900, Masahiko Sawada wrote in > On Tue, Apr 25, 2017 at 8:07 PM, Amit Kapila wrote: > > On Tue, Apr 25, 2017 at 2:09 PM, Kyotaro HORIGUCHI > >

Re: [HACKERS] Declarative partitioning - another take

On 26 April 2017 at 00:28, Robert Haas wrote: > So what I'd prefer -- on > the totally unprincipled basis that it would let us improve > performance in the future -- if you operate on a partition directly, > you fire the partition's triggers, but if you operate on the

Re: [HACKERS] scram and \password

On 04/25/2017 06:26 PM, Heikki Linnakangas wrote: Thoughts? Unless someone has better ideas or objections, I'll go implement that. This is what I came up with in the end. Some highlights and differences vs the plan I posted earlier: * If algorithm is not given explicitly,

Re: [HACKERS] PG 10 release notes

On Wed, Apr 26, 2017 at 09:34:02AM +0530, Amit Kapila wrote: > >> Just wondering if the mention of commit > >> 0414b26bac09379a4cbf1fbd847d1cee2293c5e4 is missed? Not sure if this > >> requires a separate entry or could be merged with -- Support parallel > >> btree index scans. > > > > This item

Re: [HACKERS] Cached plans and statement generalization

2017-04-26 12:30 GMT+02:00 Konstantin Knizhnik : > > > On 26.04.2017 10:49, Konstantin Knizhnik wrote: > > > > On 26.04.2017 04:00, Tsunakawa, Takayuki wrote: Are you considering some > upper limit on the number of prepared statements? > In this case we need some kind

Re: [HACKERS] Cached plans and statement generalization

On 26.04.2017 10:49, Konstantin Knizhnik wrote: On 26.04.2017 04:00, Tsunakawa, Takayuki wrote: Are you considering some upper limit on the number of prepared statements? In this case we need some kind of LRU for maintaining cache of autoprepared statements. I think that it is good idea

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

On Wed, Apr 26, 2017 at 1:25 PM, Bruce Momjian wrote: > On Wed, Apr 26, 2017 at 07:33:27AM +, Tsunakawa, Takayuki wrote: > > From: pgsql-hackers-ow...@postgresql.org > > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Masahiko > Sawada > > > The idea of changing

Re: [HACKERS] PG 10 release notes

On Tue, Apr 25, 2017 at 09:56:58PM -0400, Bruce Momjian wrote: > > SCRAM-SHA-256 improves deficiencies of MD5 password hashing by > > preventing any kind of pass-the-hash vulnerabilities, where a user > > would be able to connect to a PostgreSQL instance by just knowing the > > hash of a password

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

On Wed, Apr 26, 2017 at 07:33:27AM +, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Masahiko Sawada > > The idea of changing the default value seems good to me but I'm not sure > > it's good idea to change the

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

Magnus Hagander writes: > +1. I definitely think we should do it, and 10 would be the time to do it. Agreed. It's mainly a historical accident that the default is what it is, I think. > I wonder if we should also consider changing the standby error message to > be a

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

Nikhil Sontakke writes: > A SELECT query on the newly promoted master on any of the tables involved > in the 2PC hangs. The hang is due to a loop in > SubTransGetTopmostTransaction(). Due to incorrect linkages, we get a > circular reference in parentxid <-> subxid

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > On 2017/04/26 0:42, Stephen Frost wrote: > > I'm not sure what you mean here. We're always going to call both > > getInherits() and getPartitions() and run the queries in each, with the > > way the code is written today. In my

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

On 4/26/17 04:32, David Rowley wrote: >> For backpatching to 9.6, I came up with the attached reduced version. >> Since we don't have add_foreign_grouping_paths() in 9.6, we can omit the >> refactoring and keep the changes much simpler. Does that make sense? > > That makes sense to me. It fixes

Re: [HACKERS] PG 10 release notes

On Tue, Apr 25, 2017 at 7:19 PM, Bruce Momjian wrote: > On Tue, Apr 25, 2017 at 09:00:45AM +0530, Amit Kapila wrote: >> On Tue, Apr 25, 2017 at 8:35 AM, Bruce Momjian wrote: >> > On Tue, Apr 25, 2017 at 08:30:50AM +0530, Amit Kapila wrote: >> >> On Tue, Apr

Re: [HACKERS] Adding support for Default partition in partitioning

Hello Jeevan, Thank you for comments. I will include your comments in the updated patch. >7.The output of describe needs to be improved. The syntax for DEFAULT partitioning is still under discussion. This comment wont be applicable if the syntax is changed. >6. >I am wondering, isn't it

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

> I'm suggesting we take the approach that if there is a problem we can > recreate it as a way of exploring what conditions are required and > therefore work out the impact. Nikhil Sontakke appears to have > re-created something, but not quite what I had expected. I think he > will post here

Re: [HACKERS] PG 10 release notes

On Wed, Apr 26, 2017 at 07:38:05PM +0530, Amit Kapila wrote: > >> I have already mentioned the commit id (5e6d8d2b). Text can be "Allow > >> queries containing subplans to execute in parallel". We should also > >> mention in some way that this applies only when the query contains > >>

Re: [HACKERS] Unportable implementation of background worker start

I wrote: > =?utf-8?Q?R=C3=A9mi_Zara?= writes: >> coypu was not stuck (no buildfarm related process running), but failed to >> clean-up shared memory and semaphores. >> I’ve done the clean-up. > Huh, that's even more interesting. I installed NetBSD 5.1.5 on an old Mac G4; I

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/25/17 15:42, Petr Jelinek wrote: >> Here is the patch doing just that. > > And one more revision which also checks in_use when attaching shared > memory. This is mainly to improve the user visible behavior in > theoretical corner case when the worker is supposed to be cleaned up but >

Re: [HACKERS] Fix a typo in subscriptioncmd.c

On Wed, Apr 26, 2017 at 3:07 PM, Masahiko Sawada wrote: > Hi, > > Attached patch for $subject. > > s/accomodate/accommodate/ Pushed. Thanks! Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Wed, Apr 26, 2017 at 8:00 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 4/25/17 15:42, Petr Jelinek wrote: > >> Here is the patch doing just that. > > > > And one more revision which also checks in_use when attaching shared > > memory. This is mainly to improve the user

Re: [HACKERS] scram and \password

Robert Haas writes: > On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas wrote: >> * If algorithm is not given explicitly, PQencryptPasswordConn() queries >> "SHOW password_encryption", and uses that. That is documented, and it is >> also documented that

[HACKERS] Logical replication in the same cluster

I tried setting up logical replication on the same server between two different databases, and got, from database test: test=> CREATE TABLE test (x INT PRIMARY KEY); CREATE TABLE test=> test=> INSERT INTO test VALUES (1); INSERT 0 1 test=> CREATE

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

On 26 April 2017 at 15:28, Tom Lane wrote: > Nikhil Sontakke writes: >> A SELECT query on the newly promoted master on any of the tables involved >> in the 2PC hangs. The hang is due to a loop in >> SubTransGetTopmostTransaction(). Due to incorrect

Re: [HACKERS] scram and \password

On Wed, Apr 26, 2017 at 12:57 PM, Tom Lane wrote: > Would it be worth making password_encryption be GUC_REPORT so that > it could be guaranteed available, without a server transaction, > from any valid connection? I'm generally resistant to adding > GUC_REPORT flags, but

Re: [HACKERS] Cached plans and statement generalization

> > A naive option would be to invalidate anything that depends on table or > view *.FOOBAR. You could probably make it a bit smarter by also requiring > that schema A appear in the path. > This has been rumbling around in my head. I wonder if you could solve this problem by registering

Re: [HACKERS] [PATCH] Incremental sort

On Wed, Apr 26, 2017 at 7:56 PM, Peter Geoghegan wrote: > On Wed, Apr 26, 2017 at 8:39 AM, Alexander Korotkov > wrote: > > That appears to be wrong. I intended to make cost_sort prefer plain sort > > over incremental sort for this dataset size. But,

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

JD, * Joshua D. Drake (j...@commandprompt.com) wrote: > Does not use existing comment functionality. Alternate solution > which would decrease functionality is: > > COMMENT ON SETTING setting IS 'comment'; That seems like a pretty reasonable idea, at least from where I sit. > Looking forward,

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

On 04/26/2017 10:14 AM, Stephen Frost wrote: JD, Having COMMENT ON accept a general query whose result is then cast to text and stored as the comment would allow this to be done, eg: COMMENT ON table IS (pg_get_comment('table') || ' new text'); Dig it, although we probably want the

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

"Joshua D. Drake" writes: > I wouldn't fight hard to change it but really if we think about it, what > makes more sense from usability perspective? > CREATE TABLE foo() COMMENT IS I think it's likely to be impossible to shoehorn such a thing into every type of CREATE

Re: [HACKERS] [PATCH] Incremental sort

On Wed, Apr 26, 2017 at 8:20 PM, Peter Geoghegan wrote: > On Wed, Apr 26, 2017 at 10:10 AM, Alexander Korotkov > wrote: > > OK, I get it. Our qsort is so fast not only on 100% presorted case. > > However, that doesn't change many things in context of

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

On Wed, Apr 26, 2017 at 1:03 PM, Joshua D. Drake wrote: > Problem we are trying to solve: > > Having documentation for changes to GUC parameters that are modified via > ALTER SYSTEM. > > Why? > > Because documentation is good and required for a proper production system. >

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

Stephen Frost writes: > Having COMMENT ON accept a general query whose result is then cast to > text and stored as the comment would allow this to be done, eg: > COMMENT ON table IS (pg_get_comment('table') || ' new text'); Putting general subexpressions into utility

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

On 04/26/2017 10:31 AM, Tom Lane wrote: "Joshua D. Drake" writes: I wouldn't fight hard to change it but really if we think about it, what makes more sense from usability perspective? CREATE TABLE foo() COMMENT IS I think it's likely to be impossible to shoehorn

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

Jeff Janes writes: > This gives me compiler warning: > launcher.c: In function 'logicalrep_worker_launch': > launcher.c:257: warning: 'slot' may be used uninitialized in this function Yeah, me too. Fix pushed. regards, tom lane -- Sent via

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Having COMMENT ON accept a general query whose result is then cast to > > text and stored as the comment would allow this to be done, eg: > > > COMMENT ON table IS (pg_get_comment('table') || ' new text'); >

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

On Mon, Apr 24, 2017 at 7:06 AM, Ashutosh Bapat wrote: > This assumes that datums in partition bounds have one to one mapping > with the partitions, which isn't true for list partitions. For list > partitions we have multiple datums corresponding to the items

Re: [HACKERS] Dropping a partitioned table takes too long

On Tue, Apr 25, 2017 at 10:05 PM, Amit Langote wrote: >> The attached patch try to replace 'heap_open' with 'LockRelationOid' when >> locking parent table. >> It improved dropping a table with 7000 partitions. > > Your patch seems to be a much better solution to the

Re: [HACKERS] Dropping a partitioned table takes too long

On 4/26/17 12:15, Robert Haas wrote: > On Tue, Apr 25, 2017 at 10:05 PM, Amit Langote > wrote: >>> The attached patch try to replace 'heap_open' with 'LockRelationOid' when >>> locking parent table. >>> It improved dropping a table with 7000 partitions. >> >> Your

Re: [HACKERS] some review comments on logical rep code

On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI wrote: > At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada > wrote in > >> On Wed, Apr 26, 2017 at 12:35 PM, Petr

Re: [HACKERS] Partition-wise aggregation/grouping

On Wed, Apr 26, 2017 at 6:28 AM, Antonin Houska wrote: > Attached is a diff that contains both patches merged. This is just to prove my > assumption, details to be elaborated later. The scripts attached produce the > following plan in my environment: > >QUERY

Re: [HACKERS] subscription worker doesn't start immediately on eabled

On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI wrote: > At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut > wrote in > <3d6a1bd0-08ce-301d-3336-ec9f623a3...@2ndquadrant.com> >> On 4/6/17 08:24, Kyotaro HORIGUCHI wrote:

Re: [HACKERS] logical replication fixes

On 4/18/17 12:17, Euler Taveira wrote: > While inspecting the logical replication code, I found a bug that could > pick the wrong remote relation if they have the same name but different > schemas. Also, I did some spelling/cosmetic changes and fixed an > oversight in the ALTER SUBSCRIPTION

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

Robert Haas writes: > I'm going to say this one more time: I really, really, really think > you need to avoid trying to convert the partition bounds to a common > type. I said before that the infrastructure to do that is not present > in our type system, and I'm pretty

Re: [HACKERS] Dropping a partitioned table takes too long

Robert Haas writes: > On Tue, Apr 25, 2017 at 10:05 PM, Amit Langote > wrote: >> Your patch seems to be a much better solution to the problem, thanks. > Does anyone wish to object to this patch as untimely? > If not, I'll commit it. It's

Re: [HACKERS] Dropping a partitioned table takes too long

On Wed, Apr 26, 2017 at 12:22 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Apr 25, 2017 at 10:05 PM, Amit Langote >> wrote: >>> Your patch seems to be a much better solution to the problem, thanks. > >> Does

Re: [HACKERS] some review comments on logical rep code

On Thu, Apr 27, 2017 at 1:28 AM, Fujii Masao wrote: > On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI > wrote: >> At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada >> wrote in >>

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

Robert Haas writes: > So this is about a cross-type join, > not multiple types within a single partitioning hierarchy, as you > might also gather from the subject line of this thread. OK, but I still don't understand why any type conversion is needed in such a case. The

[HACKERS] Fix a typo in worker.c

HI, Attached patch for $subject. s/strigs/strings/ Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center fix_typo_in_worker_c.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Declarative partitioning - another take

On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote wrote: > FWIW, I too prefer the latter, that is, fire only the parent's triggers. > In that case, applying only the patch 0001 will do. Do we need to update the documentation? -- Robert Haas EnterpriseDB:

Re: [HACKERS] [PATCH] Incremental sort

On Wed, Apr 26, 2017 at 8:39 AM, Alexander Korotkov wrote: > That appears to be wrong. I intended to make cost_sort prefer plain sort > over incremental sort for this dataset size. But, that appears to be not > always right solution. Quick sort is so fast only on

Re: [HACKERS] [BUGS] ON CONFLICT with constraint name doesn't work

This is a kindly reminder, that this problem (message about "constraint" violation, while there is no such a constraint defined, just an index) is still unresolved. Let's fix that naming? Patch is attached in the previous message (posted to -bugs list) On Thu, Mar 16, 2017 at 9:15 PM, Nikolay

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

On Wed, Apr 26, 2017 at 12:19 PM, Tom Lane wrote: > What I'm going to ask one more time, though, is why we are even discussing > this. Surely the partition bounds of a partitioned table must all be of > the same type already. If there is a case where they are not, that is >

Re: [HACKERS] scram and \password

On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas wrote: > On 04/25/2017 06:26 PM, Heikki Linnakangas wrote: >> Thoughts? Unless someone has better ideas or objections, I'll go >> implement that. > This is what I came up with in the end. Some highlights and differences vs > the

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

On Wed, Apr 26, 2017 at 12:41 PM, Tom Lane wrote: > Robert Haas writes: >> So this is about a cross-type join, >> not multiple types within a single partitioning hierarchy, as you >> might also gather from the subject line of this thread. > > OK, but I

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Masahiko Sawada > The idea of changing the default value seems good to me but I'm not sure > it's good idea to change the default value now under the circumstances where > we're focus on

[HACKERS] RFC: ALTER SYSTEM [...] COMMENT

-hackers, We have had ALTER SYSTEM for some time now. It is awesome to be able to make changes that can be system wide without ever having to hit a shell but it does lack a feature that seems like an oversight, the ability to comment. Problem we are trying to solve: Having documentation

[HACKERS] Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi. Thanks for rebased patch set v12. Currently I try to use this patch on my new test site and get following: Hmm...  The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/src/include/access/parallel.h

Re: [HACKERS] [PATCH] Incremental sort

On Wed, Apr 26, 2017 at 10:10 AM, Alexander Korotkov wrote: > OK, I get it. Our qsort is so fast not only on 100% presorted case. > However, that doesn't change many things in context of incremental sort. The important point is to make any presorted test case only

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

On 26 April 2017 at 18:03, Joshua D. Drake wrote: > -hackers, > > We have had ALTER SYSTEM for some time now. It is awesome to be able to make > changes that can be system wide without ever having to hit a shell but it > does lack a feature that seems like an oversight,

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

Simon Riggs writes: > I've added code following Michael and Tom's comments to the previous > patch. New patch attached. Couple of minor suggestions: * Rather than deleting the comment for SubTransSetParent entirely, maybe make it say "It's possible that the parent was

Re: [HACKERS] Fixup some misusage of appendStringInfo and friends

On 4/19/17 08:42, Ashutosh Bapat wrote: > I reviewed the patch. It compiles clean, make check-world passes. I do > not see any issue with it. Looks reasonable. Let's keep it for the next commit fest. > > On Wed, Apr 19, 2017 at 9:13 AM, David Rowley > wrote: >>

Re: [HACKERS] Logical replication in the same cluster

Petr Jelinek writes: > On 26/04/17 18:59, Bruce Momjian wrote: >> ... it just hangs. My server logs say: > Yes that's result of how logical replication slots work, the transaction > that needs to finish is your transaction. It can be worked around by > creating the

Re: [HACKERS] Logical replication in the same cluster

On 26/04/17 18:59, Bruce Momjian wrote: > I tried setting up logical replication on the same server between two > different databases, and got, from database test: > > test=> CREATE TABLE test (x INT PRIMARY KEY); > CREATE TABLE > test=> > test=> INSERT INTO test VALUES

Re: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> It'd be better to invent inverse pg_get_comment and pg_set_comment >> functions, then you could do bulk-update things like >> select pg_set_comment('table', pg_get_comment('table') || ' more') >> from pg_class

Re: [HACKERS] Unportable implementation of background worker start

Andres Freund writes: > I'd still like to get something like your CLOEXEC patch applied > independently however. Here's an updated version of that, which makes use of our previous conclusion that F_SETFD/FD_CLOEXEC are available everywhere except Windows, and fixes some

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

On 27 April 2017 at 01:31, Peter Eisentraut wrote: > committed Great. Thanks! -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-26 11:42:38 -0400, Tom Lane wrote: > 1. Let HEAD stand as it is. We have a problem with slow response to > bgworker start requests that arrive while ServerLoop is active, but that's > a pretty tight window usually (although I believe I've seen it hit at > least once in testing). > >

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

Thanks all for your comments. > Magnus Hagander writes: > > +1. I definitely think we should do it, and 10 would be the time to do > it. > > Agreed. It's mainly a historical accident that the default is what it > is, > I think. > > > I wonder if we should also consider

Re: [HACKERS] Logical replication in the same cluster

Peter Eisentraut writes: >>> If that's a predictable deadlock, I think a minimum expectation is that >>> the system should notice it and throw an error, not just hang. > We had some discussions early on about detecting connections to the same > server, but it's

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-26 17:05:39 -0400, Tom Lane wrote: > Here's an updated version of that, which makes use of our previous > conclusion that F_SETFD/FD_CLOEXEC are available everywhere except > Windows, and fixes some sloppy thinking about the EXEC_BACKEND case. > > I went ahead and changed the call to

Re: [HACKERS] Logical replication in the same cluster

On 4/26/17 19:18, Michael Paquier wrote: >> If that's a predictable deadlock, I think a minimum expectation is that >> the system should notice it and throw an error, not just hang. (Then >> the error could give a hint about how to work around it.) But the case >> Bruce has in mind doesn't seem

Re: [HACKERS] vcregress support for single TAP tests

On 4/23/17 17:09, Andrew Dunstan wrote: > > Here's a patch that will allow calling vcregress.pl to run a single TAP > test set. It would work like this: > > > vcregress.pl src/test/recover true > > > The second argument if true (in the perl sense, of course) would trigger > a temp install

Re: [HACKERS] Fixup some misusage of appendStringInfo and friends

On 27 April 2017 at 06:41, Peter Eisentraut wrote: > On 4/19/17 08:42, Ashutosh Bapat wrote: >> I reviewed the patch. It compiles clean, make check-world passes. I do >> not see any issue with it. > > Looks reasonable. Let's keep it for the next commit fest.

Re: [HACKERS] Unportable implementation of background worker start

Robert Haas writes: > On Wed, Apr 26, 2017 at 8:37 PM, Andres Freund wrote: >>> 3. Go ahead with converting the postmaster to use WaitEventSet, a la >>> the draft patch I posted earlier. I'd be happy to do this if we were >>> at the start of a devel

Re: [HACKERS] identity columns

On 4/23/17 16:58, Robert Haas wrote: > I agree that ADD is a little odd here, but it doesn't seem terrible. > But why do we need it? Instead of: > > ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY > SET GENERATED { ALWAYS | BY DEFAULT } > DROP IDENTITY [ IF EXISTS ] > > Why not just: > > SET

Re: [HACKERS] PG 10 release notes

On Wed, Apr 26, 2017 at 8:46 PM, Bruce Momjian wrote: > On Wed, Apr 26, 2017 at 07:38:05PM +0530, Amit Kapila wrote: >> >> I have already mentioned the commit id (5e6d8d2b). Text can be "Allow >> >> queries containing subplans to execute in parallel". We should also >> >>

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Thu, Apr 27, 2017 at 5:13 AM, Oleg Golovanov wrote: > Can you actualize your patch set? The error got from > 0010-hj-parallel-v12.patch. I really should get around to setting up a cron job to tell me about that. Here's a rebased version. The things currently on my list for

[HACKERS] Re: [BUGS] BUG #14629: ALTER TABLE VALIDATE CONSTRAINTS does not obey NO INHERIT clause

On 2017/04/24 13:16, Amit Langote wrote: > On 2017/04/22 3:40, buschm...@nidsa.net wrote: >> The following bug has been logged on the website: >> >> Bug reference: 14629 >> Logged by: Hans Buschmann >> Email address: buschm...@nidsa.net >> PostgreSQL version: 9.6.2 >> Operating

Re: [HACKERS] PG 10 release notes

On Tue, Apr 25, 2017 at 8:59 AM, Bruce Momjian wrote: > On Mon, Apr 24, 2017 at 11:05:41PM -0400, Bruce Momjian wrote: >> > I think the above commit needs a separate mention, as this is a really >> > huge step forward to control the size of hash indexes. >> >> Yes, it is

[HACKERS] Crash when partition column specified twice

Noticed that a crash occurs if a column is specified twice when creating a partition: create table p (a int) partition by list (a); -- crashes create table p1 partition of parent ( a not null, a default 1 ) for values in (1); The logic in MergeAttributes() that merged partition column

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

On Thu, Apr 27, 2017 at 11:48 AM, Masahiko Sawada wrote: > Thank you for updating the patch. Also maybe we can update line in > PostgresNode.pm where hot_standby is set to on explicitly. I would refrain from doing that, having some parameters listed in the tests makes the

Re: [HACKERS] scram and \password

On Tue, Apr 25, 2017 at 8:56 PM, Heikki Linnakangas wrote: > On 04/22/2017 01:20 AM, Michael Paquier wrote: > >> On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas >> wrote: >> >>> I'll continue reviewing the rest of the patch on Monday, but one glaring >>>

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

On Wed, Apr 26, 2017 at 9:52 PM, Magnus Hagander wrote: > > I wonder if we should also consider changing the standby error message to > be a WARNING instead of an ERROR. So that if you try to start up a standby > with hot_standby=on but master with wal_level=replica it would

Re: [HACKERS] Logical replication in the same cluster

On Wed, Apr 26, 2017 at 6:02 PM, Tom Lane wrote: > Petr Jelinek writes: >> On 26/04/17 18:59, Bruce Momjian wrote: >>> ... it just hangs. My server logs say: > >> Yes that's result of how logical replication slots work, the transaction >> that

Re: [HACKERS] Fix a typo in worker.c

On 4/26/17 12:43, Masahiko Sawada wrote: > Attached patch for $subject. > > s/strigs/strings/ done, thanks -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

[HACKERS] Inefficient shutdown of pg_basebackup

I griped before that the src/test/recovery/ tests take an unreasonably long time. My interest in that was piqued further when I noticed that the tests consume not very much CPU time, and aren't exactly saturating my disks either. That suggests that the problem isn't so much that the tests do too

Re: [HACKERS] scram and \password

On Wed, Apr 26, 2017 at 7:22 PM, Heikki Linnakangas wrote: > We talked about the alternative where PQencryptPasswordConn() would not look > at password_encryption, but would always use the strongest possible > algorithm supported by the server. That would avoid querying the

Re: [HACKERS] Logical replication in the same cluster

On Thu, Apr 27, 2017 at 7:02 AM, Tom Lane wrote: > Petr Jelinek writes: >> On 26/04/17 18:59, Bruce Momjian wrote: >>> ... it just hangs. My server logs say: > >> Yes that's result of how logical replication slots work, the transaction >> that

  1   2   >