Re: [HACKERS] Logical replication in the same cluster

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 needs to finish is your transaction. It can be worked

Re: [HACKERS] Logical replication in the same cluster

On 4/27/17 15:06, Peter Eisentraut wrote: > On 4/27/17 04:08, Petr Jelinek wrote: >> Note that the workaround for all of this is not all that complex, you do >> same thing (create slot manually) you'd do for physical replication with >> slots. > > Maybe we should just document this issue for now.

Re: [HACKERS] Logical replication in the same cluster

On 02/05/17 16:37, Andres Freund wrote: > On 2017-05-02 09:17:27 +0200, Petr Jelinek wrote: >> Yes because otherwise we risk leaving slot on the upstream if the >> command fails downstream. > > Shouldn't temporary slots be able to solve that concern? Create it as > temporary at the beginning,

Re: [HACKERS] Logical replication in the same cluster

On 2017-05-02 09:17:27 +0200, Petr Jelinek wrote: > Yes because otherwise we risk leaving slot on the upstream if the > command fails downstream. Shouldn't temporary slots be able to solve that concern? Create it as temporary at the beginning, mark it as permanent at the end? Greetings, Andres

Re: [HACKERS] Logical replication in the same cluster

On 02/05/17 04:14, Peter Eisentraut wrote: > On 4/30/17 20:31, Andres Freund wrote: >> On 2017-04-26 23:41:51 +0200, Petr Jelinek wrote: >>> 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 >>>

Re: [HACKERS] Logical replication in the same cluster

On 4/30/17 20:31, Andres Freund wrote: > On 2017-04-26 23:41:51 +0200, Petr Jelinek wrote: >> 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 slot manually via the SQL interface for

Re: [HACKERS] Logical replication in the same cluster

On 1 May 2017 at 19:24, Andres Freund wrote: >> There is no inherent reason why the CREATE INDEX CONCURRENTLY style of >> using multiple transactions makes it necessary to leave a mess behind >> in the event of an error or hard crash. Is someone going to get around >> to

Re: [HACKERS] Logical replication in the same cluster

On Mon, May 1, 2017 at 11:37 AM, Andres Freund wrote: > What exactly are you proposing to do? You mean catching errors in the > creating backend, if it didn't crash? That is what I meant, though I'm not actually proposing to do anything. > That doesn't strike me as a good >

Re: [HACKERS] Logical replication in the same cluster

On 2017-05-01 11:31:53 -0700, Peter Geoghegan wrote: > On Mon, May 1, 2017 at 11:24 AM, Andres Freund wrote: > > Doing catalog changes in recovery is frought with problems. Essentially > > requires starting one worker per database, before allowing access. > > Do you think

Re: [HACKERS] Logical replication in the same cluster

On Mon, May 1, 2017 at 11:24 AM, Andres Freund wrote: > Doing catalog changes in recovery is frought with problems. Essentially > requires starting one worker per database, before allowing access. Do you think it's worth just covering the case where you get an error, such as

Re: [HACKERS] Logical replication in the same cluster

On 2017-05-01 11:22:47 -0700, Peter Geoghegan wrote: > On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas wrote: > > On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek > > wrote: > >> Back when writing the original patch set, I was also playing with the

Re: [HACKERS] Logical replication in the same cluster

On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas wrote: > On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek > wrote: >> Back when writing the original patch set, I was also playing with the >> idea of having CREATE SUBSCRIPTION do multiple committed

Re: [HACKERS] Logical replication in the same cluster

On 2017-04-26 23:41:51 +0200, Petr Jelinek wrote: > 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 slot manually via the SQL interface for example and create > the subscription using

Re: [HACKERS] Logical replication in the same cluster

On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek wrote: > Back when writing the original patch set, I was also playing with the > idea of having CREATE SUBSCRIPTION do multiple committed steps in > similar fashion to CREATE INDEX CONCURRENTLY but that leaves mess behind

Re: [HACKERS] Logical replication in the same cluster

On 4/27/17 04:08, Petr Jelinek wrote: > Note that the workaround for all of this is not all that complex, you do > same thing (create slot manually) you'd do for physical replication with > slots. Maybe we should just document this issue for now. -- Peter Eisentraut

Re: [HACKERS] Logical replication in the same cluster

On 27/04/17 04:50, Tom Lane wrote: > 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

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] 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] 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] 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

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 Wed, Apr 26, 2017 at 11:41:51PM +0200, Petr Jelinek wrote: > 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); > >

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

[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